Re: [Caml-list] The Bytecode Interpreter...

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

From: Jonathan Roewen <jonathan.roewen@gmail.com>

> I've noted on the computer language shootout that ocaml bytecode is
> slow compared to Java. I'm curious, are there any plans to optimise
> the shit out of the bytecode interpreter? I know it has been a goal to
> not be much more than 1.3x slower than C -- but this only covers
> ocamlopt/native code. Don't you think bytecode should have some
> endeavour to match or better some other language too (Java seems best
> case to me in this scenario).
> 
> About the only thing the shootout proves is that ocaml bytecode has
> very good memory use compared to Java.

This is not at all surprising: you are comparing two very different
things. OCaml has a pure bytecode interpreter, while Java is a mix of
interpreter and run-time compiler (the famous "JIT"). Microsoft's CLR
is even more extreme, as all execution goes through the JIT. Their
only common point is that they take bytecode as input, but they run it
very differently. For a pure bytecode interpreter OCaml is pretty fast
(faster than caml-light, which was already very fast), but it cannot
compete with a compiler. There is also an experimental JIT runtime for
OCaml (ocamljitrun), but it suffers from the difference in the
bytecode design: OCaml bytecode is designed to run on a pure bytecode
interpreter, so it drops all type and control flow information (which
Java bytecode keeps), as it would not be useful for such an
interpreter. The advantage is compactness, and good memory use. This
also means that there is very little the JIT will be able to
optimize. Nonetheless ocamljitrun is about twice as fast as ocamlrun,
just because modern processors are very much geared towards compilers.

So your question could be expressed as: is there any plan for a more
expressive bytecode, that would allow JIT optimizations.
The answer is that I'm not aware of any.
A connected topic may be the language F#: a cousin of ocaml, built on
top of Microsoft's CLR, and as such benefiting from a very good JIT
runtime.

That's all I know.

Jacques Garrigue