<div dir="auto"><div>Joe,<div dir="auto"><br></div><div dir="auto">The answer is multiple schedulers.</div><div dir="auto"><br></div><div dir="auto">In the days before the SMP enabled Erlang emulator (VM) we would need to run multiple nodes (VM) to take advantage of multiple cores. Now the default mode for the VM is to run as many schedulers as there are cores available. This also highly configurable.</div><div dir="auto"><br></div><div dir="auto">Although Erlang's distribution allows processes to transparently communicate across nodes there is a great performance advantage in intra-node messaging as there is reference passing and it avoids serialization in the external term format.</div><div dir="auto"><br></div><div dir="auto">It's interesting though how everything goes in cycles. Five years ago I was keeping the core counts very high, and the node counts very low, to get great performance. Now with cloud native we run a node in a container and communicate with other (microservices) nodes using either distribution or external protocols (e.g. REST) so the overheads are again much higher. But the old way was vertical scaling and this is horizontal scaling, we pay a tax but go from dozens of cores to hundreds or thousands.</div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 13, 2018, 08:46 joe mcguckin <<a href="mailto:joe@via.net">joe@via.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
If erlang is one large unix process with hundreds or thousands of it's own processes internally, how does Erlang make maximum use of a multi-core cpu?<br>
<br>
Wouldn’t Erlang be scheduled and run on a single core ?<br>
</blockquote></div></div></div>