CPU/Hardware optimized for Erlang
Thu Jul 28 12:46:58 CEST 2005
Den 2005-07-28 11:37:14 skrev Thomas Lindgren <>:
> Slide 14 in the ECOMP presentation is a bit unclear:
> did you get 30x speedup on the call control software
> vs the BEAM/UltraSparc setup above? Or was this on
> other benchmarks vs the BEAM/UltraSparc? Or vs some
> other baseline?
I believe that the result of the prototype was that we
could match our 450 MHz Ultra with a <20 MHz FPGA, and
that a 200 MHz ECOMP ASIC would:
- fit nicely into the corner of our switch port chip
- run circles around the UltraSPARC
- use about 1/10 of the power
> Also, does the line "measured per use of clock cycles"
> on slide 14 mean that the 30x speedup was 1/30 the
> number of clock cycles were used running on ECOMP vs
> the UltraSparc for the benchmark(s)?
Yes, the prototype was run in a VHDL simulator and an
ECOMP emulator written in Erlang. To compare performance,
clock cycles were counted. While the Ultra is capable of
executing up to 4 instructions per clock cycle, we got
slightly less than 1 instruction per cycle on our erlang
code. I don't know how wait states in ECOMP were accounted
for, but one point of using a threaded architecture was
that ECOMP would be able to switch to another process
while waiting for data (or whatever), thus reducing the
number of actual wait states in the processor.
> That aside, and most importantly: did you decide to go
No. The main reason was that it would have required a
rather extensive redesign of our software at the time
(not the move to ECOMP in itself, but moving call control
farther out towards the interfaces, rather than having a
central processor handling several interfaces. Nowadays,
we do more or less this (one call control cpu per interface),
but this transition took a long time, and other events
(most importantly, Robert T. was reassigned) meanwhile
caused the ECOMP project to go into hibernation.
More information about the erlang-questions