[erlang-questions] Why are messages between processes copied?
Thu Feb 23 13:52:07 CET 2012
The original reason is that "the destination process might be on
Imagine process A sends a message to PidB (ie says PidB ! Msg)
We're not supposed to know where PidB is (physically) - now suppose
Pib is either on the same
machine OR a different machine - the failure semantics are *entirely
different* - we don't want any danging references. We don't want a
pointer on the machine hosting PidB to point to
a machine that has crashed.
Getting this to work consistently with failures is very difficult -
sharing pointers makes it even more difficult.
Now it so happens that on modern massive multicores and in particular
large network on chip architectures, message passing times between
cores varies a lot - if the cores are adjacent
(on the chip) it can be very fast - but if they are separated this can
take far longer (I have seen factors of 60 here) - but once copied
data access becomes a local operation and is pretty fast.
Once copied to a different core GC becomes a parallel operation - this is
In the future we can expect this trend to continue - message passing
to nearby cores will be
quick and to far away cores expensive - so it absolutely makes sense
to perform the expensive
operation once (copying) and the cheap operation (accessing local
data) fast (which it would not
be if it were via a pointer to a remote core) .
Erlang accidentally has the right properties to exploit multi-core
architectures - not by design
but by accident. The underlying reason was to make the semantics of
local and remote failures the same.
On Wed, Feb 22, 2012 at 11:22 PM, H. Diedrich <hd2010@REDACTED> wrote:
> Hi list,
> I had naively thought that Erlang would be sending process messages around
> profiting from the fact that data is immutable and NOT copying it. And
> really just send a 'pointer'.
> Why is that not so, it should be a huge gain from immutable data, especially
> with bigger data. You don't have to copy, knowing that your data is
> Thanks for a link or a brief,
> erlang-questions mailing list
More information about the erlang-questions