On Nov 16, 2010, at 18:07 , bluestorm wrote: > 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:
Thanks for posting these points, should have done this in my original post... > 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...). With the x86 port being close to complete, direct comparison with OcamlJIT will be possible (dunno if OcamlJIT will work with 3.12 tho). I'll do appropriate comparisons once everything is in place. > 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`). This is indeed debatable, atleast for "ocamlc -help". But this was not the main concern with LLVM. LLVM overhead is acceptable for long running computations, but everything else is slowed down noticably. It should also be noted that my LLVM prototype was rather quick&dirty, so it may indeed be possible to get a LLVM based JIT which is on par with the byte-code interpreter for common applications. But why would one want to do this? Long running computations can be speed up very well using ocamlopt (no need to perform them using the interactive top-level). > 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. It used AsmJit before, which is also limited to x86/x86-64; the non-portability is actually a design decision (as explained in my original post, portability to non-desktop machines was not a goal for the current implementation). HTH, 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
