4 ms·

A crucial question for fast execution of the BEAM-machine on multiple cores is how expensive message copying between cores is. With that many cores, there's pro

by mafribe 10y ago

A crucial question for fast execution of the BEAM-machine on multiple cores is how expensive message copying between cores is. With that many cores, there's probably no shared memory between all cores. How do the remaining cores communicate? Can the BEAM machine's optimisations take into account communication cost?

yellowapple 10y ago
I don't know very much about BEAM's internals, but one of the key reasons why Erlang (and therefore Elixir) is able to spin up so many processes is because the processes don't have shared state, or at least they don't have writable shared state; the underlying data structures are all immutable, and this is enforced on a VM level (which is why Elixir's "mutability" is only in terms of which data a given variable holds rather than the data itself). Given that, my guess would be that Erlang/Elixir/LFE/$INSERT_OTHER_BEAM_BASED_LANGUAGE_HERE would do pretty darn well with a high number of cores. I hope one of these days I'll be able to afford such a machine (whether with this particular ARM processor or something else with a ridiculous number of cores/threads, like a modern POWER or SPARC CPU) or have access to one so that I can experience for myself exactly how darn well :) It's also worth noting that Erlang has had a lot of design around clusters of independent nodes, which means even more extreme problems when it comes to data copying between nodes. I reckon intercore message copying is significantly more performant than internode message copying.
- mafribe 10y ago
  Do you know what kinds of optimisations Erlang/BEAM does for clusters of independent nodes? Does the user have to tell Erlang/BEAM which thread lives on what node, or does the scheduler handle this automatically?
  - yellowapple 10y ago
    Internode process spawning happens explicitly, last I checked. It's pretty easy once both nodes are communicating, but not automatic. In contrast, BEAM's SMP support is automatic AFAICT; the scheduler will happily distribute processes across as many cores as it can access (1 BEAM thread per hardware thread by default, so a quad-core CPU with one thread per core and a dual-core CPU with two threads per core will both be loaded with four BEAM threads unless BEAM is configured to do something else).

by mafribe 10y ago

yellowapple 10y ago

I don't know very much about BEAM's internals, but one of the key reasons why Erlang (and therefore Elixir) is able to spin up so many processes is because the processes don't have shared state, or at least they don't have writable shared state; the underlying data structures are all immutable, and this is enforced on a VM level (which is why Elixir's "mutability" is only in terms of which data a given variable holds rather than the data itself). Given that, my guess would be that Erlang/Elixir/LFE/$INSERT_OTHER_BEAM_BASED_LANGUAGE_HERE would do pretty darn well with a high number of cores. I hope one of these days I'll be able to afford such a machine (whether with this particular ARM processor or something else with a ridiculous number of cores/threads, like a modern POWER or SPARC CPU) or have access to one so that I can experience for myself exactly how darn well :) It's also worth noting that Erlang has had a lot of design around clusters of independent nodes, which means even more extreme problems when it comes to data copying between nodes. I reckon intercore message copying is significantly more performant than internode message copying.

mafribe 10y ago
Do you know what kinds of optimisations Erlang/BEAM does for clusters of independent nodes? Does the user have to tell Erlang/BEAM which thread lives on what node, or does the scheduler handle this automatically?
- yellowapple 10y ago
  Internode process spawning happens explicitly, last I checked. It's pretty easy once both nodes are communicating, but not automatic. In contrast, BEAM's SMP support is automatic AFAICT; the scheduler will happily distribute processes across as many cores as it can access (1 BEAM thread per hardware thread by default, so a quad-core CPU with one thread per core and a dual-core CPU with two threads per core will both be loaded with four BEAM threads unless BEAM is configured to do something else).