[erlang-questions] Forget Erlang on the Java VM. More language on the Erlang VM are needed!

[Joe Armstrong]

On Nov 29, 2007 4:35 PM, James Hague <james.hague@REDACTED> wrote:
> On Nov 28, 2007 7:34 AM, Joel Reymont <joelr1@REDACTED> wrote:
> >
> > Write Lisp on the Erlang VM, write Haskell or a new language with an
> > elegant syntax. Throw your lot into improving the existing VM.
>
> Agreed 100%.  The Erlang VM is fantastic in a number of ways.  It
> supports the features that make Erlang great: message passing,
> lightweight processes.  It's also one of the fastest dynamic language
> VMs out there.  Plus it's easy to map imperative languages to Erlang
> (http://prog21.dadgum.com/5.html).

I'll let you into a secret ...

The behaviour of the VM is not particularly surprising - it does what
it was designed
to do. When we built the first VM years ago Mike Williams laid down
the strategy for the
VM. His view was that for a concurrent language there where three
things that were
important above all else:

  - context switching time
 - message passing time
 - process spawning time

The first VM (The JAM) compiled A ! B into

(code to push A on top the stack)
(code to push B on top the stack)
send

send was a single byte code that the VM evaluated.

Mike who write the first jam emulator started hard at the assembler
that the C compiler
generated and fiddled with his program to make this as efficient as possible.

Other languages prioritise other things - fast function calls, fast lookup in a
method call chain and so on.

The Erlang VM is perceived as fast because it does the concurrency bit
better than other language - it is a consequence of the design of the VM.
The VM was designed to do this kind of thing very quickly.

Many languages are slow only because you have to evaluate large numbers of
instructions to get them to do what you want.

If the VM and the language are not a good fit - then no matter how hard you
work performance will suck.

A nice example of this is LUA - the VM fits the language nicely so the
implementation
is surprising small and fast. Same for smalltalk.

Contrary to what has been said here I'm not convinced that the Erlang VM
is a good target for "other" languages. The VM was designed specifically for
Erlang - so I think the fit with languages with other semantics might
not be so good.

If you look at the pascal P code machine, the Erlang VM, the smalltalk
VM the LUA VM
you see that there are opcodes especially suited for implementing
these languages.

I fear that general purpose VMs will be always have lack lustre
performance compared to purpose built VMs.

If the VM is a bad language match then you have to play horrible
tricks to get the
implementation to work. For example compiling Erlang to the JVM would
be a mess - because although the JVM has
reasonable stack handling instructions it's idea of a heap is very
different to Erlangs - as is the JVMs idea
of garbage collection. Note that the design of the Erlang VMs also
have to think about the type of
GC you want so that this is reasonably fast and perceived as real time.

Were I think the Erlang implementation could be improved is by
implementing the GC and scheduler
in Erlang itself - you'd need some kind of inlining to inline VM
instructions in Erlang that are known not
to produce garbage - the emulator itself should also be written in
Erlang (using the inline VM opcodes) and
then cross compiled to C - or just straight to assembler. This is how
smalltalk and various lisps are implemented.

To get high performance out of a VM you have to sit down with a pencil and paper
and count instruction cycles and cache hits, designing things so that
the VM matches up with
what your language is supposed to do. This is not particularly
difficult - but it takes a long time.

Writing such a system is a "thought bound" process - the result is not
a lot of code - but you have to think
for a long time and do lot's of small experiments before writing it.

If you do compile some other language to the Erlang VM it should work
- but you might not get the
great performance you were dreaming of.  You will also bear with you
all the things in the
Erlang run-time system that you dare not remove - the things that are
needed by Erlang but not needed
by a new language.

>
> And now a question: what's the best target for compiling to?  Real
> Erlang?  Core Erlang?  BEAM?  I'm probably alone in this opinion, but
> I think a light layer of syntactic sugar on top of raw, BEAM code
> would be a fun and productive language--and even more flexible than
> Erlang.  But relying on the BEAM VM to remain stable isn't reasonable.

An RTL that can be cross compiled to a MIPS or Intel processor or to C
or emulated by C :-)

(Actually I think VMs should have even more layers)

Erlang -> EVM -> ERTL -> MIPS (ERTL = Erlang register transfer language)

you could emulate the ERTL in C or transform it to C

/Joe Armstrong

>
> James
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>