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

Ladislav Lenart lenartlad@REDACTED
Fri Aug 8 11:21:04 CEST 2014


Hello.

Thank you. This, with other responses to this thread, answers my (perhaps
ill-phrased) question.

I knew that OS processes and Erlang processes are different beasts, but I did
not realize that it is such a deal breaker.

Again, thank you all for your valuable answers,

Ladislav Lenart


On 8.8.2014 01:58, ok@REDACTED wrote:
>>>> 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