Re: Green threads in 1.9.* ?

On Sun, Jul 8, 2012 at 2:19 AM, rex goxman <[e-mail]> wrote:

> I am reading Erlang documentation right now which which states that an
> Erlang process doesn't amount to much more than a pointer within the
> Erlang VM pointing off to some chunk of code/memory inside the Erlang
> VM, which explains why the processes are so lightweight.
>

Erlang processes have separate heaps and are independently garbage
collected, however within the SMP scheduler they share the same address
space across cores. While they have an affinity for particular schedulers,
since they operate in a shared address space any scheduler can potentially
execute them.


> Erlang didn't change the processes.  It didn't change the threading.  It
> added a scheduler and the infrastructure to allow the green processes
> living within the VM to be scheduled across VMs running on other cores.
> Erlang's own docs recommend running only one VM in a single thread per
> core, because it says you aren't going to get any speedup if you add
> more threads and more VMs per core.
>

You're colluding the word "virtual machine" with schedulers running within
the virtual machine. If I launch BEAM for example:

$ erl
Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:8:8] [rq:8]
[async-threads:0] [hipe] [kernel-poll:false]

This is a single instance of the Erlang virtual machine. However you will
note smp:8 and rq:8. This is because this single instance of the Erlang
virtual machine is running 8 scheduler threads, one for each core of my
computer:

Eshell V5.8.5  (abort with ^G)
1> erlang:system_info(schedulers).
8


> That's entirely incorrect, because you could have one thread running on
> each core, with a single GREEN-THREADED VM running on each of those
> threads (x cores, x threads total, x VMs running total).  This is what
> Erlang does now.  The only thing different now than in the past is that
> the VMs will communicate back and forth and schedule their GREEN THREADS
> across each other.


Again, there's only one instance of BEAM, i.e. there is only one virtual
machine, however there are 8 schedulers running inside it. These schedulers
each have their own thread, however they share an address space and contend
on things like memory allocation (again, because there's only one virtual
machine with a single pool of resources that much be shared among
schedulers).

In the past, when Erlang really did use green threads, it was necessary to
run a single Erlang VM per CPU core and use distributed Erlang (even in a
single system) to get multicore parallelism. However, now that Erlang has
an SMP scheduler, one Erlang VM can run a scheduler thread per CPU core and
affect multicore parallelism that way.

-- 
Tony Arcieri