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

Michael Turner michael.eugene.turner@REDACTED
Thu Feb 23 13:00:05 CET 2012

Richard underscores an important point: one reason to keep apparent
communication costs high is that, to a good first approximation, they
already *are* high in real life and (compared to CPU operation costs)
will only go higher.

A major revelation for me when I took a VLSI design course a few
decades ago: digital signals crossing chips don't move at the speed of
light, they take *quadratic* time as a function of distance. And we
haven't even started talking about power requirements, especially when
signals have to propagate off the chip.

One might take great comfort in a shared heap, thinking "ah, there's
so little copying now." But if stuff has to get copied around the
memory hierarchy anyway (albeit transparently via cache coherence and
cache replenishment), you're not really winning much. You might
*think* you're enjoying a wealth of computer power. But spare a
thought for the hapless geek who inherits your code and is asked to
repartition your system so that processes that used to share an
address space no longer do. What might have been performance
bottleneck so wide as to be only subliminally confining will narrow
down to ... the hypodermic needle through the camel's eye. And camels
can kick hard. (They also spit, I'm told.) The caravan will move on
without you, while you desperately repack everything the right way,
and beg rides from others. So much for your wealth of computing power
then, eh?

-michael turner

On Thu, Feb 23, 2012 at 8:05 AM, Richard O'Keefe <ok@REDACTED> wrote:
> On 23/02/2012, at 11:22 AM, H. Diedrich wrote:
>> 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.
> Did you ever do metalwork at school?
> They teach you: "see that bump in the metal?  If you just bang that flat with a hammer, the
> distortion will just pop up somewhere else.  You have to smooth things out by tapping gently
> all over the place, spreading the distortion out so it's not noticeable."
> It's like that with computing costs.  If you make one thing cheaper, you often make something
> else more expensive.  Messages should normally be *small*, so that they are cheap to copy (any
> bulk data is normally a binary, and large binaries *are* shared between processes within a
> node).  Sharing a heap means that garbage collection is now a nasty lots-of-threads-interacting-
> with-a-giant-mutable-data-structure problem, affecting *everything* all the time.
> A shared heap has been tried for Erlang, and it will doubtless be tried again in the future.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list