The Zen of Parallel Programming

Post by trollbridge » Mon, Jul 20, 2026, 6:17 PM UTC

reinitctxoffset wrote: post #40

trollbridge wrote: post #39

Earlier quoted context omitted.

For greenfield work, we are using mostly Rust, although small utilities built with Go or Python are also acceptable provided they have a comprehensive set of unit tests, an integration test suite, well-defined specifications and acceptance criteria, and thorough documentation. Once you have that, it's much easier for the AI to work on it. (Our main motivation for doing this is that it takes far fewer tokens now to ge…

I'll contend that any Rust build involving Cargo is bloated and slow. `rustc` is impressively slow on a translation unit basis, and Cargo is basically a build recursion bingo card. Throw in about 900 micro point releases in flight at any given time? If you're not running an elite `bazel` or `buck2` RBE with `nativelink`? You're not even playing.

Post by reinitctxoffset » Tue, Jul 21, 2026, 3:30 AM UTC

trollbridge wrote: post #41

reinitctxoffset wrote: post #40

Earlier quoted context omitted.

I'll contend that any Rust build involving Cargo is bloated and slow. `rustc` is impressively slow on a translation unit basis, and Cargo is basically a build recursion bingo card. Throw in about 900 micro point releases in flight at any given time? If you're not running an elite `bazel` or `buck2` RBE with `nativelink`? You're not even playing.

I make sure projects are split into much smaller units so we don’t need some gargantuan bazel based build. Having a bloated, barely-maintainable codebase and a build that takes hours and needs 100GB of storage is not a badge of honour.

Post by locallost » Thu, Jul 23, 2026, 2:12 PM UTC

CyberDildonics wrote: post #44

locallost wrote: post #30

Earlier quoted context omitted.

Amdahl's law says something similar, adding more processors to a problem eventually gives almost no speedup because parts of the problem cannot be parallelized and need to be done sequentially. To the people wondering the meaning of the article, it's I think this.

amdahl's law is trivial tautological nonsense and has nothing to do with the mythical man month. The mythical man month is about communication between people and the amount of work to be productive in a project. It's about people colliding with programming. It has nothing to do with a vague statement that "eventually" you have diminishing returns on processors (of course there is some limit even though different task…

Post by locallost » Fri, Jul 24, 2026, 12:10 AM UTC

CyberDildonics wrote: post #46

locallost wrote: post #45

Earlier quoted context omitted.

Amdahl's law states diminishing returns are because some processes cannot be parallelized, thus eventually they become the bottleneck. For Brooks the communication between people starts to dominate the time spent the more people you add, so it will eventually become the bottleneck. For me it's an interesting parallel. Feel free to come up with your own conclusions.

thus eventually they become the bottleneck It's completely obvious and the "eventually" is where anything interesting happens. This comes from the early days of computers which is why something trivial became a supposed insight. For Brooks the communication between people starts to dominate the time spent the more people you add, so it will eventually become the bottleneck. Not just the communication between people w…

Post by locallost » Fri, Jul 24, 2026, 6:36 PM UTC

CyberDildonics wrote: post #48

locallost wrote: post #47

Earlier quoted context omitted.

You try to speed up work by parallelizing, either by adding more machines or more humans. Seems pretty similar.

It might seem obvious if you don't think about it much, but one is a pragmatic breakdown from experience and one just says "adding cpus won't work forever if there is some part where you can't add more cpus". One is basically 1 + 1 = 2 and the other is a warning of a non obvious situation that comes from lots of experience and effort.