3 ms·
> CPU parallelism by forking. Which, minus the IPC, code/dependency sharing, has similar practical consequences as Erlang/Elixir: no shared heap. > but instea
by 15155 11y ago
> CPU parallelism by forking.
Which, minus the IPC, code/dependency sharing, has similar practical consequences as Erlang/Elixir: no shared heap.
> but instead of using callbacks/promises
At a level as high as JavaScript this doesn't matter, but, green threads are not as performant as this model would be in a lower-level language.
Edge-triggered, multi-threaded event loops + callbacks are a force to be reckoned with on the concurrency front.
> 99th percentile latency
Single-core tests? For both Erlang (BEAM) and Node.js?
I'd like to see this testing and the reasoning behind it, though if true, I suspect it's probably related to GC latency (and the high cost of JS execution contexts).
- rubiquity 11y ago> Which, minus the IPC, code/dependency sharing, has similar practical consequences as Erlang/Elixir: no shared heap. In Elixir/Erlang every Erlang process has its own heap. In the case of Node.js and forking, each forked process has its own heap. You can't fork 100,000 times but you can have 100,000+ Erlang processes all with separate heaps and all in the same process.