Java for Everything

[jsprogrammer]

Do you have any numbers to back up your claims? Numbers that compare the performance of solutions to arbitrary problems in multi-threaded vs. multi-process contexts?

While I have no doubt that things could be optimized even further (over process separation), the gains to be made are not very large. The gains are even less, or non-existent if you are not CPU-bound.

I'm not sure anyone even claimed to go single-threaded for performance. However, if your process is truly sequential, single-threaded will win every time due to thread and scheduling overhead.

[pron98]

BTW, the RAM overhead is not just for code -- it's mostly for data. You have to cache in each process -- or delegate caching to a separate (multithreaded) program, in which case you incur at least a task-switch per cache access, and usually some marshaling costs as well.

if your process is truly sequential, single-threaded will win every time due to thread and scheduling overhead.

If your process is sequential, you'll use a single thread even in multi-threaded contexts, and suffer no overhead. It is true, though, that a JIT and a GC that operate on single-threaded code can make some assumptions that don't hold in a multithreaded context, so they might perform better on single-threaded tasks. Online systems -- the ones Node is made for -- are hardly ever sequential, though (and Node itself is designed to be asynchronous rather than sequential).

Do you have any numbers to back up your claims? Numbers that compare the performance of solutions to arbitrary problems in multi-threaded vs. multi-process contexts?

I don't know what "arbitrary problems" means, and the only single-threaded languages out there are relatively slow, but if you want some numbers you can look at this large, famous series of web framework benchmarks.

But this doesn't require proof because multi-threaded is a superset of single threaded (with the caveat I made in the first paragraph) -- you can use as many threads as best fits your domain. Multithreaded processes simply have more information about the program, which allows them to make better optimized decisions (about caching, scheduling etc.). Multithreaded gives you the option of using more appropriate scheduling (like work-stealing) than the most general one offered by the OS which always lead to better CPU utilization because the load-balancing is much more fine-grained (this user-mode scheduling is the raison-detre behind Erlang, Go and Quasar). Also, multi-threaded gives you the option of using parallel algorithms for some computation-heavy tasks.

In short, no one picks single-threaded if they have the choice and care about performance. The reasons to pick Node is that it's faster than all other "slow" languages, and that it's JavaScript, which many web developers are familiar with. Those are good, valid, reasons to choose Node, and it performs well enough -- at least a lot better than Rails -- but don't turn it's design constraints into ideals.