<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi Joe<br><br>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.<br><br>Matt<br><br>> Date: Thu, 23 Feb 2012 13:52:07 +0100<br>> From: erlang@gmail.com<br>> To: hd2010@eonblast.com<br>> CC: erlang-questions@erlang.org<br>> Subject: Re: [erlang-questions] Why are messages between processes copied?<br>> <br>> The original reason is that "the destination process might be on<br>> another machine"<br>> <br>> Imagine process A sends a message to PidB (ie says PidB ! Msg)<br>> <br>> We're not supposed to know where PidB is (physically) - now suppose<br>> Pib is either on the same<br>> machine OR a different machine - the failure semantics are *entirely<br>> different* - we don't want any danging references. We don't want a<br>> pointer on the machine hosting PidB to point to<br>> a machine that has crashed.<br>> <br>> Getting this to work consistently with failures is very difficult -<br>> sharing pointers makes it even more difficult.<br>> <br>> Now it so happens that on modern massive multicores and in particular<br>> large network on chip architectures, message passing times between<br>> cores varies a lot - if the cores are adjacent<br>> (on the chip) it can be very fast - but if they are separated this can<br>> take far longer (I have seen factors of 60 here) - but once copied<br>> data access becomes a local operation and is pretty fast.<br>> <br>> Once copied to a different core GC becomes a parallel operation - this is<br>> good :-)<br>> <br>> In the future we can expect this trend to continue - message passing<br>> to nearby cores will be<br>> quick and to far away cores expensive - so it absolutely makes sense<br>> to perform the expensive<br>> operation once (copying) and the cheap operation (accessing local<br>> data) fast (which it would not<br>> be if it were via a pointer to a remote core) .<br>> <br>> Erlang accidentally has the right properties to exploit multi-core<br>> architectures - not by design<br>> but by accident. The underlying reason was to make the semantics of<br>> local and remote failures the same.<br>> <br>> /Joe<br>> <br>> <br>> <br>> On Wed, Feb 22, 2012 at 11:22 PM, H. Diedrich <hd2010@eonblast.com> wrote:<br>> > Hi list,<br>> ><br>> > I had naively thought that Erlang would be sending process messages around<br>> > profiting from the fact that data is immutable and NOT copying it. And<br>> > really just send a 'pointer'.<br>> ><br>> > Why is that not so, it should be a huge gain from immutable data, especially<br>> > with bigger data. You don't have to copy, knowing that your data is<br>> > immutable.<br>> ><br>> > Thanks for a link or a brief,<br>> > Henning<br>> > _______________________________________________<br>> > erlang-questions mailing list<br>> > erlang-questions@erlang.org<br>> > http://erlang.org/mailman/listinfo/erlang-questions<br>> _______________________________________________<br>> erlang-questions mailing list<br>> erlang-questions@erlang.org<br>> http://erlang.org/mailman/listinfo/erlang-questions<br> </div></body>
</html>