To those of you who are lazy but still curious, I just read the report, and here are the answers to the question I had:

1. Is that project related to Basile Starynkevitch's venerable OCamlJIT ?

Yes, OcamlJIT was apparently a major inspiration for this work. The overall design is similar, and in particular the objective of absolute compatibility with the existing bytecode (even when it may hurts performances) was retained. Unfortunately, due to bitrotting and different architectures (OcamlJIT x86 vs. OcamlJIT2 x86_64), there is no direct performance comparison, though the reports seems to indicate similar to better performances. Several points were also improved (better (but still suboptimal) register usage, clever hacks to speed up mapping between bytecode and native code adresses...).

2. Does it use LLVM ?

No, it doesn't, but it's justified. Apparently, an early prototype showed than LLVM compilation/generation overhead was too high. A (debatable) design goal of OcamlJIT2.0 is to be absolutely faster than ocamlrun, even on *very* short-running programs (`ocamlc -help`). Here is a direct quote from the report :
In a simple OCamlJit2 prototype based on LLVM, we have measured significant
compilation overhead; short running programs (like ocamlc applied to a small to medium
sized *.ml file) were three to four times slower than running the same program with the
byte-code interpreter. Similar results were observed by other projects using LLVM for
Just-In-Time compilation. For example, the Mono project10 reported impressive speedups
for long running, computationally intensive applications, but at the cost of increased com-
pilation time and memory usage.

OCamlJIT2.0 uses its own macro to generate x86_64 assembly directly (apparently using a dedicated library wasn't worth it). A drawback of this strategy is its inherent non-portability.


3. Does it perform well ?

As explained in the original post, the speedups against bytecode are around 2-6x. It's quite honourable, and the results are very consistent: all benchmarked programs running for more than 1 second have speedups between 2.59 and 5.34.

The authors seems to think other optimizations are possible, and expect significant performance improvements in the future. The goal of being "on par with the ocaml native compiler" is (prudently) mentioned. On the benchmark, ocamlopt was itself 2 to 6 times faster than OcamlJIT2.0.


4. Various remarks:

Various clever hacks are described in the report, which bring noticeable performance improvements but probably make the implementation more complex.
I was also interested by the following remark --- maybe a bit provocative:

Both JVM and CLR depend on profile guided optimizations for good performance,
because their byte-code is slower than the OCaml byte-code. This is mostly because of
the additional overhead that comes with exception handling, multi-threading, class loading
and object synchronization. But it is also due to the fact that both the JVM byte-code [27]
and the Common Intermediate Language (CIL) [10] instruction sets are not as optimized
as the OCaml byte-code.



On Tue, Nov 16, 2010 at 3:52 PM, Benedikt Meurer <benedikt.meurer@googlemail.com> wrote:
Hello everybody,

OCamlJit 2.0 is a new Just-In-Time engine for Objective Caml 3.12.0 on desktop processors (x86/x86-64). It translates the OCaml byte-code used by the interpreter (ocamlrun and ocaml) to x86/x86-64 native code on-demand and runs the generated native code instead of interpreting the byte-code. It is designed to run with minimal compilation overhead (translating only what is being executed, avoiding costly code generation and optimization techniques), while being 100% compatible with the byte-code runtime (including serialization and hashing of closures, etc.).

OCamlJit 2.0 was specifically designed for desktop processors and is not really portable to anything else in its current shape, because the target audience are people using the interactive top-level and the byte-code interpreter for rapid prototyping/development (which is unlikely to happen on anything else but x86/x86-64). The implementation currently requires a system that adheres to the SysV ABI, which includes Linux, BSD, OS X, but excludes Win32/Win64 (patches/ideas are welcome). It was tested on Linux/x86 (Debian), Linux/amd64 (CentOS) and Mac OS X 10.6 (64bit). The x86 implementation requires SSE2 capable processors (otherwise it falls back to the byte-code interpreter), so it won't speedup your OCaml programs running on 486 CPUs. :-)

OCamlJit 2.0 runs most benchmarks at 2-6 times faster than the byte-code interpreter. The interactive top-level benefits twice when used with the JIT engine: (a) the compiler stages are JIT compiled and (b) the generated byte-code is JIT compiled. A tech report describing a slightly earlier prototype and including performance measures of OCamlJit 2.0 on Mac OS X (64bit) is available at:

 http://arxiv.org/abs/1011.1783

The source code is available from the Git repository (master branch) at:

 http://gitorious.org/ocamljit2/ocamljit2

Installation is similar to installation of Objective Caml, just run

 ./configure -prefix /path/to/ocamljit2 [options]

followed by

 make world opt
 make install

This will install a fully working Objective Caml 3.12.0 to /path/to/ocamlji2, where /path/to/ocamljit2/bin/ocamlrun and /path/to/ocamljit2/lib/libcamlrun_shared.so include the JIT engine in addition to the byte-code interpreter (fallback to the byte-code interpreter is necessary for debugging with ocamldebug). The configure script prints a line indicating whether the JIT engine is enabled or not (if not, it'll be just a regular OCaml 3.12 installation).

Comments are welcome.

Enjoy!

Benedikt Meurer

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs