[erlang-questions] how are erlang process lightweight?

[Bob Ippolito]

On 10/3/06, Ben Dougall <bend@REDACTED> wrote:
>
> On Tuesday, October 3, 2006, at 12:58  pm, Sean Hinde wrote:
>
> > On 3 Oct 2006, at 12:25, Ben Dougall wrote:
> >
> >> So that seems to be the thing, so far as memory footprint goes:
> >> threads
> >> have a stack and that stack is, as usual, made up or an indefinite
> >> number of frames -- potentially many/infinite -- grows per new
> >> function
> >> call. Whereas Erlang processes are tied very tightly (one to one) to
> >> functions, and a function's memory usage amount to one frame of a
> >> stack. So an Erlang process is limited to a frame of a stack.
> >
> > This is where you are going wrong. An erlang function is only related
> > to a process in the sense that processes evaluate functions. Each
> > process has its own stack that can grow/shrink as much as it needs.
> >
> > It is not nearly as different to pthreads as you describe. The
> > efficiency gains of Erlang are *only* those of being able to optimise
> > process switching and do custom memory management.
>
> I've just coming to that conclusion from Richard's reply, as from what
> he was saying there is not much difference between thread and Erlang
> process memory footprints.
>
> > Erlang processes are actually more akin to UNIX processes as they do
> > not share state. Think of them as exactly like UNIX processes with
> > much less overhead and much nicer message passing.
>
> Yes I understand that. It was how they've ended up so light is what I
> was interested in. And I now realise that it's the fact that it's all
> (the switching etc.) handled in user space by the Erlang system where
> the efficiency/saving comes from. So it's not so much a saving of
> memory space (although I guess there is at least a bit of memory space
> saving) but a saving in the amount of memory-shifting-round that the
> machine needs to do. Less memory-shifting-round is necessary with E.P.s
> than threads.

The way switching is done and the contract that Erlang processes have
with the scheduler are different than with pthreads. The fixed
overhead Erlang process overhead is less than what it takes just to
save the state of all the CPU registers on some platforms (if it is on
the order of 16-32 words)! Also, the stack of a pthread has to be
preallocated and of a fixed size, and there's other bookkeeping that
pthreads do that Erlang processes do not have to.

So, switching is faster and processes are cheaper. If pthreads didn't
suck, we wouldn't be here ;)

-bob