[erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux?

ok <>
Fri Aug 8 01:58:05 CEST 2014


>>> Linux (and Solaris and HP-UX and ...) are constrained by
>> having to present a C/POSIX ABI.  And C is an amazingly
>> low-level language (operational definition: you cannot
>> shift the stack because you have no way of telling what
>> is in it).
>>
>> The two systems are simply solving different problems
>> under different constraints.


> Both Linux and Erlang manage processes and Erlang is (much?) better at it.
> Again, I just wanted to know why...

Re-read what I said about C/POSIX ABI and "solving different problems".

Linux and Erlang do *NOT* both manage processes,
and Erlang is *NOT* better at what Linux does than Linux is.
They both manage things *called* processes, and at a
sufficiently abstract level the things are entitled to the
name, but that's seriously misleading.
Let me put it this way, marmosets and gorillas are both
primates in good standing, but a marmoset weights about
a quarter of a kilo and fits comfortably in your hand.
I think you'll agree that it's going to be a LOT easier
to house and feed 100 marmosets than 100 gorillas.

Let's start with the very low level.  A modern x86_64 has
16 64-bit general registers
16 256-bit vector registers
 8 80-bit floating-point registers
 1 32-bit flags register
 1 64-bit program counter
other assorted things like performance counters.

Switching between *threads* in the same UNIX process
could therefore involve storing 732 bytes of registers
from the old thread and load 732 byte of registers
from the new thread.

Something like the Erlang VM can arrange to switch only
at points where all of the floating point registers and
the flags are known to be dead, so a context switch
between Erlang processes only needs to save and restore
about 18% of the information that a Linux *thread* switch
does.  (Oh wait, I forgot that threads in Linux use the
FS segment register for thread-locals.  The 732 byte
figure is *definitely* low.)

Here I've compared Erlang processes to Linux threads.
Linux *processes* have even more hardware state to switch.
Performance counters will definitely be there, as will
memory management registers.  Some machines have
watchpoint registers for debugging.  You'd be *amazed*
at what has to be switched.

As for process creation, think about the fact that
every Linux process has its own page tables and no
Erlang process does.

Relying on software to prevent one process scribbling
on the memory of another has good consequences.





More information about the erlang-questions mailing list