News for hackers. Stuff that matters.
Re:Napa.js: A multi-threaded JavaScript runtime by drderidder on Wednesday October 18, 2017 @11:14AM (#15499768)
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.
Re:Napa.js: A multi-threaded JavaScript runtime by immutable_ai on Wednesday October 18, 2017 @06:06PM (#15503649)
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.

Re:Napa.js: A multi-threaded JavaScript runtime by datavirtue on Wednesday October 18, 2017 @12:24PM (#15500466)
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.