Hacker News Reader

Comment by paulddraper | Hacker News Reader

The distinguishing factor between multi-processing on one machine and multi-"machining" is latency of communication.

Likewise, the distinguising factor between multi-threading and multi-processing is shared memory, i.e. again, the speed of communication.

Multi-threading does well for some problems, but often, multi-machining or multi-processing is sufficient, which is why so many runtimes don't really do multi-threading: Node.JS, Python, Ruby.

View on HN

Very true, and we've seen better performance from multi-process than multi-threading in some high-traffic (10Gbps) systems (those were C++ however, not node). It was puzzling, but I put it down to the OS scheduler; I imagine that a single multi-threaded process would be pre-empted in the typical fashion, but that multiple single-threaded processes would, in aggregate, spend less time in a pre-empted state.

Context switching is expensive and very tempting to forget about in multi-threaded development. You eliminate that overhead constraining the execution code to a single thread context.

Yes, multi-threading has high overhead to provide the illusion of parallel operation, but when all the cores are saturated you are in the same boat, whether you have 1 or 100.

The benefit to programs that don't use threading and use event loop and shared nothing multi-process is that they don't have the overhead when things are maxed out.

This is why virtually every high performance server (nginx, redis, memcached, etc) is written this way and things like varnish (thread per request) are multiples or orders of magnitude slower.

Funny people criticizing nodejs for using the same architecture that all the best-in-class products use.

Note that Python does do multithreading - just the actual Python interpreter will not interpret Python code from two threads at once. If threads are busy running code that doesn't require the interpreter, whether it is CPU bound work or not, then as many threads can run as you have cores. In most CPU bound applications, the performance critical parts are not pure Python - they're calling out to some extension code such as numpy or cython or something. Such code runs in parallel in CPython if you start multiple threads.

This might have been what you meant when you said the runtime isn't really multi-threaded - but since the CPython ecosystem rests so heavily on C code, in practice multithreading is a good solution a lot of the time.

Right. And Ruby also has a GIL.

Node.JS, Python, and Ruby are in C/C++ so you can do multithreading in all three, if you are willing to write native modules.

Yes. Python gets all the heat for the GIL, but most similar languages have something with more or less the same effect.

If you're careful you can release the GIL when writing Cython code.

Better than C/C++ sometimes.

Reply on news.ycombinator.com