CPU/Hardware optimized for Erlang

[Ulf Wiger]

Den 2005-07-27 13:41:21 skrev Thomas Lindgren <thomasl_erlang@REDACTED>:

> Well, ECOMP had 30x speedup compared to JAM, not BEAM.



> On similar programs at that time, HIPE had a 10-20x
> speedup over JAM (when compiling JAM bytecodes to
> Sparc asm), if memory serves. So, assuming no further
> compiler improvements, ECOMP would have to remain
> within a factor of 3 or so of the desktop systems, to
> be competitive in speed.

AFAIK, in 2000, AXD 301 was using BEAM (we never did use
JAM in the final product), and the most relevant
benchmark was compiling a call control prototype to
ECOMP and comparing it to the same code running on
the AXD 301 target platform with 450 MHz UltraSPARC 2i
processors with Solaris and BEAM.


> At that time, power wasn't really on the map, but
> presumably a similar comparison could be made by
> porting BEAM or HIPE to a suitable incumbent.

For us, power was very much on the map. That was one
reason why SPARC could be competitive to Intel at
the time. We had a 20W power budget for the CPU board,
if memory serves.


> So, I seriously doubt the viability of rewriting some
> emulator or interpreter in silicon, which is the
> closest I can think of "executing the language
> directly". Every few years, someone comes up with a
> new BEAM but you will then be stuck with JAM.

But this is not what ECOMP did. The ECOMP compiler
prototype - written by Peter Lundell on his spare
time, while working as our System Project Manager
- hooked into the OTP compiler framework, about at
the same level as beam_asm, I think. As such, it
ought to have been fairly future-proof.

ECOMP had an instruction set modeled after the Erlang
language -- not any specific virtual machine. It was
designed to handle garbage-collected languages (with
sub-instructions for reference counting) without
global variables (a deep register file). On average,
one line of Erlang would correspond to 3 ECOMP
instructions.

Most of the BIFs needed for the prototype were actually
implemented in plain Erlang, and not optimized at all.
Some things, like ETS, were hand-written in ECOMP
assembly, but ETS ended up being fairly simple tuple
trees.


/Uffe
-- 
Ulf Wiger