Erlang on "Cell" Architectures
Wed Feb 9 07:37:08 CET 2005
Geoff White writes:
> IT [cell] seems like an architecture that is just ripe for Erlang (or a
> derivative language).
I have three takes on this:
The work which seems most closely related is something I vaguely
recall Dr Fergus O'Brien at RMIT talking about. He was (thinking
about?) adapting Erlang for some massively parallel custom (?)
machine. I don't know if that was a real machine or something
that was going to be built and I never heard about it again.
So far, Cell is vapour. Before cell, "emotion engine" was going to
radically change the world. At some point it was grid computing.
Before that it was "blades". Before that, "network computing".
Before that, Erlang-on-FPGA/ASIC. Before that, it was 2 and 4
way SMP PCs/servers. And before that, Erlang on massively
parallel architectures. And, in the beginning, it was Amiga. ;-)
When you say "concurrent" in the context of programming languages,
most people automatically think "a way to speed up software by
exploiting parallel hardware." Often, the expectation is that the
software will be parallelised automatically and in a very
fine-grain way, e.g. that a loop will be unrolled 'across' multiple
But the primary benefit of concurrency in Erlang to me is
"a simpler way to structure software in a domain where there is
a lot of natural concurrency". I.e. I'm not writing concurrent
code because I'm chasing a performance win. I'm writing concurrent
code because it's simpler and has more desirable characteristics
in the event of a fault. I'm not using concurrency because the
underlying hardware allows parallel execution (it doesn't).
My existing code won't gain anything by being run on today's
garden-variety parallel hardware (e.g. 2-way SMP PCs, clusters or
blades) on today's Erlang VM. I suspect the same holds for most
More information about the erlang-questions