Hacker News Reader

Comment by bjourne | Hacker News Reader

Latest decade in software engineering indicate that multi-processing is much preferable over multi-threading. It's the architecture Edge, Firefox, and Chrome uses. So the question is what use cases multi-threading address that are not already covered by multi-processing? The memory overhead that multiple processes cause is relatively insignificant on recent machines with 32GB+ of ram.

View on HN

Browsers use multiple processes for security and reliability, not as an alternative to multi-threading. They extensively use multi-threading for performance (as does a lot of other modern software).

Firefox and Chrome run hundreds of threads… (Just have a look at htop yourself.)

Both things aren't exchangeable, of course!

Thread have direct access to process memory. Other processes usually don't. Big difference!

I don't think anyone is unilaterally going to move to multiprocess as a programming paradigm. Web browsers have their own reasons for using Multi-process, including security from memory isolation, resilience against crashes in the client side code, killing individual tabs, and so on.

I'd wager the vast majority of programs being written that need concurrency or parallelism still use multi threading or SIMD.

This must be browser specific, as servers still use threading. The 32GB mentioned is very small as well, we run up to 1.5TB nodes.

I don't understand how the choice of servers being multi threaded affects browsers being multi process

If anything, we've seen that the memory overhead of threads is unacceptably high, that's why everything these days uses thread pools / green threads / async. Multiprocessing is a niche - way too much memory usage, way too high communication cost.

Tons of use cases! There are lots of concurrent algorithms that use locking and shared memory instead of message-passing. Matrix multiplication or tree search come to mind.

Parallel blocked n^3 matrix multiplication doesn't use any synchronization primitives (short of join). The processes read from the same input matrices, but write to non-overlapping regions of memory. This is easily accomplished using posix shared memory. Indeed, this is how it is done when the matrices to be multiplied are too large to be handled by single worker nodes.

Reply on news.ycombinator.com