Erlang on "Cell" Architectures

[Matthias Lang]

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:

Anecdotal:

   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. 

Cynical:

   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. ;-)

Off-on-a-tangent:

   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
   CPUs.

   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
   Erlang software.

Matt