Erlang on "Cell" Architectures

[Richard A. O'Keefe]

Matthias Lang <matthias@REDACTED> wrote:
	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. 
	
This was the Magnus project.  I have some documentation about Magnus,
which I don't think I'm allowed to quote.  To be honest, I don't know
how far anyone got in building an actual Magnus machine.  But it was to
be based around an interconnect that was certainly real and interesting.
And the EC compiler was intended to be the Erlang compiler for Magnus,
as well as for conventional UNIX systems.  Ah, found something of Lawrie
Brown's on the web I can quote:
    Magnus
      * a massively scaleable computing platform
        * separate parallel activities
        * message passing
        * non-blocking interconnect
      * implementation to use
        * DMA @ bus speed across switch
        * WDM passive optical switch
        * Erlang

Lawrie Brown and Maurice Castro should know a lot about this.
I've heard a few rumours; let's just say the problems RMIT ran into
were financial and political rather than technical.

	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.
	
Let's not forget that first and foremost, Cell is a *GAME* engine.
It's meant for things like MPEG decoding, real-time ray tracing (maybe?),
for the kinds of things the GPUs are good at.  We're talking about fairly
regular array or stream crunching here.  It's more general than that, though.
It has "Cray-style vector processor brought up to date" written all over it.
People in the High Performance Fortran community have decades of experience
building compilers for hardware not unlike this and writing applications to
exploit it.  My preferred programming language for taking advantage of a
Cell would probably be ZPL, I just hope someone does a ZPL port.

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

Right.  An APU in a Cell is basically a SIMD machine.  And Erlang is a MIMD
language.  Erlang on a Cell would get little direct benefit from the APUs.

	   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.
	
Don't overlook the possibility that the vector processing units could be
useful for accelerating data base operations.  There ought to be _some_
way to speed up ETS and parts of DETS using the APUs.  Then there is the
potential of doing compression and/or encryption in APUs at the same time
as routing decisions are made on the PU.