3 ms·

You have some serious prejudiced opinion about how to effectively do work division to achieve either for concurrency or parallelism. My only suggestion read so

You have some serious prejudiced opinion about how to effectively do work division to achieve either for concurrency or parallelism. My only suggestion read some concurrency patterns and most importantly try to implement them using modern JS features before making such statements. May be you can find this link as starting point - https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

derefr 7y ago
What I'm talking about is how to effectively saturate multiple CPU cores in mixed IO+CPU-bound workloads, e.g. compiling/parsing, OLAP data-analysis/reporting workloads, etc. Javascript's primitives get you 1. the ability to cooperatively multitask within each thread, and 2. the ability to copy data between threads, but this is, in the end, just what you get from a pure NUMA (e.g. GPGPU, DSP) architecture. There is a reason that multicore UMA CPUs exist; there is a (very large) niche of workloads they specialize in. JS cannot currently saturate CPUs in such workloads. See, in your own link, the n-body and regex-redux benchmarks. These are examples of workloads that actually take advantage of the kind of memory-sharing / "message passing carrying reference handles" IPC that multicore UMA CPU architectures are designed to accelerate. Note V8's core saturation on these workloads. The kind of workloads that can currently be parallelized in Node, are the exact kind of workloads that are better run off-CPU anyway, in cards like GPUs or FPGAs dedicated to the niche of pure-NUMA workloads.
- truth_seeker 7y ago
  I shared the link to look at all examples and yes its not the end of the world, it's starting point. But like i said you are prejudiced to only look at where NodeJS lags behind. NEITHER you understand the simple fact that its not required to pass messages every now and then between master and worker threads, it can be done in batches NOR you care to look at JS and find there is something like SharedArrayBuffer. I will say again, please don't guess, write the code for real life use case, invest some time learning new JS API and only then compare benchmarks.

derefr 7y ago

What I'm talking about is how to effectively saturate multiple CPU cores in mixed IO+CPU-bound workloads, e.g. compiling/parsing, OLAP data-analysis/reporting workloads, etc. Javascript's primitives get you 1. the ability to cooperatively multitask within each thread, and 2. the ability to copy data between threads, but this is, in the end, just what you get from a pure NUMA (e.g. GPGPU, DSP) architecture. There is a reason that multicore UMA CPUs exist; there is a (very large) niche of workloads they specialize in. JS cannot currently saturate CPUs in such workloads. See, in your own link, the n-body and regex-redux benchmarks. These are examples of workloads that actually take advantage of the kind of memory-sharing / "message passing carrying reference handles" IPC that multicore UMA CPU architectures are designed to accelerate. Note V8's core saturation on these workloads. The kind of workloads that can currently be parallelized in Node, are the exact kind of workloads that are better run off-CPU anyway, in cards like GPUs or FPGAs dedicated to the niche of pure-NUMA workloads.

truth_seeker 7y ago
I shared the link to look at all examples and yes its not the end of the world, it's starting point. But like i said you are prejudiced to only look at where NodeJS lags behind. NEITHER you understand the simple fact that its not required to pass messages every now and then between master and worker threads, it can be done in batches NOR you care to look at JS and find there is something like SharedArrayBuffer. I will say again, please don't guess, write the code for real life use case, invest some time learning new JS API and only then compare benchmarks.