<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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.<br>
    <br>
    Cheers,<br>
    <br>
    <br>
    <br>
    [1]: <a class="moz-txt-link-freetext" href="http://www.erlang.org/euc/08/euc_smp.pdf">http://www.erlang.org/euc/08/euc_smp.pdf</a><br>
    [2]:
    <a class="moz-txt-link-freetext" href="http://erlang.org/pipermail/erlang-questions/2001-April/003132.html">http://erlang.org/pipermail/erlang-questions/2001-April/003132.html</a><br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 06/08/14 15:30, Guilherme Andrade
      wrote:<br>
    </div>
    <blockquote cite="mid:53E23BEC.3000107@gandrade.net" type="cite">
      <pre wrap="">Hello Ladislav,

On 06/08/14 15:15, Ladislav Lenart wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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?
</pre>
      </blockquote>
      <pre wrap="">
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.


</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Guilherme

<a class="moz-txt-link-freetext" href="https://www.gandrade.net/">https://www.gandrade.net/</a>
PGP: 0x35CB8191 / 1968 5252 3901 B40F ED8A  D67A 9330 79B1 35CB 8191
</pre>
  </body>
</html>