Re: [Caml-list] OCamlJit 2.0

[bluestorm <bluestorm.dylc@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6213 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 10980 bytes --]