[erlang-questions] Why are messages between processes copied?

[Joe Armstrong]

On Thu, Feb 23, 2012 at 2:15 PM, Matthew Evans <mattevans123@REDACTED> wrote:
> Hi Joe
>
> Taking this a bit further, I've often wondered if you would gain anything
> having some kind of process to core affinity. Trying to ensure that
> processes that exchange lots of messages with one another run on the same
> core.

Yes and no :-)

There is a basic assumption in erlang - that time taken for Pid ! Msg depends
upon the size of the Messang an *not* upon Pid - assuming Pid is on
the same node. This may or may not be true on a multi core - it
depends very much on the chipset/motherboard/...

You can improve performance on a multicore by pinning processes to a
particular core - but the core will be very non-portable - ideally the
Erlang
run-time will figure out where to place processes for you - but this is
an area of performance tuning that is not well understood.

Moving processes around so they run on the same core is something
we should investigate.

As with all optimisations the best advice is "don't"

/Joe


>
> Matt
>
>> Date: Thu, 23 Feb 2012 13:52:07 +0100
>> From: erlang@REDACTED
>> To: hd2010@REDACTED
>> CC: erlang-questions@REDACTED
>
>> Subject: Re: [erlang-questions] Why are messages between processes copied?
>>
>> The original reason is that "the destination process might be on
>> another machine"
>>
>> 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
>> good :-)
>>
>> 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.
>>
>> /Joe
>>
>>
>>
>> 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
>> > immutable.
>> >
>> > Thanks for a link or a brief,
>> > Henning
>> > _______________________________________________
>> > erlang-questions mailing list
>> > erlang-questions@REDACTED
>> > http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions