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

Ladislav Lenart lenartlad@REDACTED
Thu Aug 7 11:05:46 CEST 2014


Hello.

I would like to thank you for the links to various documents and blogs you
posted. Very interesting stuff.

Ladislav Lenart


On 6.8.2014 17:08, Peer Stritzinger wrote:
> Also recommend reading:
> 
> 
> http://jlouisramblings.blogspot.de/2013/01/how-erlang-does-scheduling.html
> 
> 
> -- Peer
> 
> 
> On 2014-08-06 14:33:57 +0000, Guilherme Andrade said:
> 
> 
> If you'd like more detail, I propose you read upon the low-level bells and
> whistles the process scheduler consists of, and it should become more intuitive
> by then. No need to look at source-code; a quick web search returns some
> straightforward stuff[1][2] that seems to be what you're looking for.
> 
> 
> Cheers,
> 
> 
> 
> 
> [1]: http://www.erlang.org/euc/08/euc_smp.pdf
> 
> [2]: http://erlang.org/pipermail/erlang-questions/2001-April/003132.html
> 
> 
> 
> On 06/08/14 15:30, Guilherme Andrade wrote:
> 
> Hello Ladislav,
> 
> 
> On 06/08/14 15:15, Ladislav Lenart wrote:
> 
> Is it because Erlang process occupies an order of magnitude less space than an
> 
> OS process?
> 
> Is it because a userspace scheduler such as Erlang VM is faster at process
> 
> switching? If so, why is that?
> 
> Is it somehow related to Erlang's share nothing philosophy? If so, how exactly?
> 
> Something else?
> 
> Partially, yes. Some reasons I can think of:
> 
> 
>     - Much smaller process footprint; Erlang processes aren't visible to
> 
> the OS, their footprint is much lighter (the context they need to keep
> 
> track of, etc.) OS processes are traditionally heavy, even more-so than
> 
> OS threads, which are pretty big themselves.
> 
> 
>     - By not being visible to the OS, context & execution switching
> 
> between different processes by the scheduler doesn't have to deal with
> 
> userland/kernelspace shenanigans (for the most part, anyway.)
> 
> 
>     - By being shared-nothing, traditional concurrency control
> 
> mechanisms (which have considerable overhead -- specially on SMP
> 
> machines) are not needed;
> 
> 
>     - Shooting in the dark here, but the per-process GC might also help
> 
> on this -- concerning stability and expectable availability variations,
> 
> anyway.
> 
> 
> 
> With some oversimplifications, of course; but this is the general idea.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 
> erlang-questions mailing list
> 
> erlang-questions@REDACTED<mailto:erlang-questions@REDACTED>
> 
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> 
> -- 
> 
> Guilherme
> 
> 
> https://www.gandrade.net/
> 
> PGP: 0x35CB8191 / 1968 5252 3901 B40F ED8A  D67A 9330 79B1 35CB 8191
> 
> <image>





More information about the erlang-questions mailing list