CPU/Hardware optimized for Erlang

[Thomas Lindgren]

--- James Hague <james.hague@REDACTED> wrote:

> Thomas Lindgren wrote:
> >(And why would the erlang chip have comparable
> >performance at lower power?)
> 
> I wasn't talking about a 3GHz Erlang processor using
> less power than,
> say, a 3GHz Pentium 4 (though I suspect it would). 
> I was musing about
> an Erlang processor that gives performance roughly
> equivalent to the
> BEAM *emulator* running on a 3GHz Pentium 4.  

Sure, that's what I was thinking about too.

> Using the old ECOMP
> numbers, I'm guessing that this could be done with
> an Erlang processor
> running in the ballpark of 100MHz.

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.

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.

> To a lot of programmers, a super micro CPU is simply
> a platform to
> write interpreted Python, Perl, REBOL, etc.  Or
> Erlang.  

(Even 'very dynamic' languages can be compiled
efficiently on stock hardware; cf. Self or CMUCL. I
have recently seen a python analyzer based on
Self-like class analysis too.)

> Cutting out
> the middleman and designing the hardware to execute
> the language
> directly is certainly going to be more efficient.

Maybe I'm a pessimist, but why would it be so? That
is, from all I have seen of Lisp Machines, dataflow
machines, 5th gen Prolog machines, Smalltalk machines
(SOAR, or perhaps the "Recursiv", anyone remember that
one?), Java chips -- none of them has been
competitive. The Lisp Machines came closest, doing
very well indeed for a while, but Lucid showed that
Lisp on stock hardware could do equally well. (And
maybe there is a niche for Java chips -- we will see.)

As someone whose name I can't remember liked to ask in
situations like this, "what has changed?" Why is it
going to be different this time?

Designing out the middleman sounds like "closing the
semantic gap", which sets my hackles on end :-)
Closing the semantic gap was about providing
high-level machine instructions so that programmers
could express their intentions more clearly in their
asm programs. RISC trounced the "semantic gap" theory
so hard it wasn't even funny. (Well, the funny part
was hearing sonorous pronouncements in the class room
one year about how we should overcome the semantic
gap, and then seeing all that rapidly reduced to dust
:-)

The particular point made at that time was that an
optimizing compiler could do at least as well as fancy
high-level instructions. (And usually far better.)

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.

At each point, you would instead do well to ask
whether the feature can be emulated with a "regular"
instruction sequence, and what you gain compared to
that option. (Those who like Prolog can compare the
WAM to the BAM as an example.)

> This is different
> than the long ago debates on the subject, in which
> people (Wirth, et
> al) would compare writing a *compiler* for an off
> the shelf CPU vs.
> designing a custom processor.  In this case we're
> talking about looser
> dynamic languages.

I assume Wirth et al were comparing payoff for effort?
E.g., is it more fruitful to just write a better
compiler for the money you will spend on building the
hardware, etc? An engineering trade off.

When offering a new system, you would on the other
hand have to compare your system with the best the
competition can offer, which would at a guess be a
suitable port of OTP. The hardware design would have
to plan for this, of course.

> On a related note, you could design an interesting
> cache architecture
> for a language without destructive updates.

What would that be?

Best,
Thomas



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs