Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Zen of Parallel Programming

smolnero.com

Post reply on HN
Print view View original

11–20 of 50 posts

Re: The Zen of Parallel Programming

#11

Post by LtdJorge »

toast0 wrote: post #10
ctkhn wrote: post #8

Earlier quoted context omitted.

I wonder how much a good process of meetings, tickets or whatever sort of documents etc for handling new ideas and features would speed this up or bring it back to linear. I've been in some orgs where good organization at the level above me can make the required communication between me and other dev teams lower and let us live in "good" silos

What really seems to make a difference is how well the project and the organization are at being split into indepedent groups. I've been on projects where everybody needs to know everything, and on projects where many groups can be insulated from others. The more your group can work without needing a meeting with other groups, the more things can progress in parallel. Some projects won't work well with that constrain…

It’s like distributed transactions, or cache-coherency protocols for CPUs.

Edit: aaaand I hadn’t read the article

Re: The Zen of Parallel Programming

#12

Post by reinitctxoffset »

ctkhn wrote: post #8
datadrivenangel wrote: post #7

Fred Brooks and the mythical man month observed that communication between people expands faster than linear, and that adding more people to a project makes it later.

I wonder how much a good process of meetings, tickets or whatever sort of documents etc for handling new ideas and features would speed this up or bring it back to linear. I've been in some orgs where good organization at the level above me can make the required communication between me and other dev teams lower and let us live in "good" silos

I think it's kind of fun now. Agents can interact with Linear. I'm still playing around with like does an issue achieve anything? What is the fastest way to get a bug from the observing session to the originating session?

But it's secondary.

The wall is build. If you can AI program, your problem is the build is too slow, too unreliable, not secure enough from a supply chain standpoint.

That is where one competent senior hacker tops out today. The agents are yielding to a CI that gets 35% per-vCPU occupancy.

The wall right now is skill or build, depending on your skill.

Re: The Zen of Parallel Programming

#13

Post by dwattttt »

toast0 wrote: post #10
ctkhn wrote: post #8

Earlier quoted context omitted.

I wonder how much a good process of meetings, tickets or whatever sort of documents etc for handling new ideas and features would speed this up or bring it back to linear. I've been in some orgs where good organization at the level above me can make the required communication between me and other dev teams lower and let us live in "good" silos

What really seems to make a difference is how well the project and the organization are at being split into indepedent groups. I've been on projects where everybody needs to know everything, and on projects where many groups can be insulated from others. The more your group can work without needing a meeting with other groups, the more things can progress in parallel. Some projects won't work well with that constrain…

I've heard that project architecture has a strong enough impact on feature completion rate that you can infer how tightly coupled vs loosely plugin based it is just from graphs of feature release.

Re: The Zen of Parallel Programming

#14

Post by AdieuToLogic »

datadrivenangel wrote: post #7

Fred Brooks and the mythical man month observed that communication between people expands faster than linear, and that adding more people to a project makes it later.

> Fred Brooks and the mythical man month observed that communication between people expands faster than linear, and that adding more people to a project makes it later.

In my experience with more than a couple dozen software projects, the ideal team size to successfully deliver a non-trivial effort is between five to nine people.

  One subject matter expert visionary
  One technical architect visionary
  One or two technical masters
  One or two UI/UX masters
  One or two padawans capable of becoming a master
Staffing exceeding the above for an individual team is more a managerial genitalia contest than anything focused on organizational success.

Re: The Zen of Parallel Programming

#15

Post by trollbridge »

reinitctxoffset wrote: post #12
ctkhn wrote: post #8

Earlier quoted context omitted.

I wonder how much a good process of meetings, tickets or whatever sort of documents etc for handling new ideas and features would speed this up or bring it back to linear. I've been in some orgs where good organization at the level above me can make the required communication between me and other dev teams lower and let us live in "good" silos

I think it's kind of fun now. Agents can interact with Linear. I'm still playing around with like does an issue achieve anything? What is the fastest way to get a bug from the observing session to the originating session? But it's secondary. The wall is build. If you can AI program, your problem is the build is too slow, too unreliable, not secure enough from a supply chain standpoint. That is where one competent sen…

What are you talking about? A properly prompted agent generates a project with a fast, reproducible, and isolatable build. One of the best things about agentic AI is that I spend far less time on devops and on waiting on builds.

Re: The Zen of Parallel Programming

#16

Post by reinitctxoffset »

trollbridge wrote: post #15
reinitctxoffset wrote: post #12

Earlier quoted context omitted.

I think it's kind of fun now. Agents can interact with Linear. I'm still playing around with like does an issue achieve anything? What is the fastest way to get a bug from the observing session to the originating session? But it's secondary. The wall is build. If you can AI program, your problem is the build is too slow, too unreliable, not secure enough from a supply chain standpoint. That is where one competent sen…

What are you talking about? A properly prompted agent generates a project with a fast, reproducible, and isolatable build. One of the best things about agentic AI is that I spend far less time on devops and on waiting on builds.

There are low-insensity regimes where it's all Python or whatever, and if you're in one, great.

When you're dealing with multiple platforms, or hardware accelerators, or mostly all of economically relevant shit in the AI era you don't get a small, clean, fast build.

Fable can't print a Tauri faux-native app without dragging in half of LLVM.

Re: The Zen of Parallel Programming

#17

Post by FullGarden_S »

Communication in this sense is pretty common in Mathematics and Computer Science and it becomes apparent when its related to actors and their interactions.

A good example is game theory and game semantics. The term "actor" in this context are soo abstract that we can pretty much attempt to implement them anywhere we see fit and that I think is the beauty.

Re: The Zen of Parallel Programming

#19

Post by torginus »

I cannot make sense of a single word of this essay. What sort of insight am I missing? There's not a peep here about write barriers, futexes, OS schedulers, critical paths and/or how they relate to Zen or whatever. This article can be easily recycled as the Zen of compiler design or Zen of audio engineering or whatever, without substantially having to chance much of the words, thats how generic it is.

I'm genuinely considering that this is just a foreword and I missed the clickthrough link to the meat of the article.

Post reply on HN