Re: [Caml-list] OCamlJIT2 vs. OCamlJIT

[Benedikt Meurer <benedikt.meurer@googlemail.com>]

On Nov 30, 2010, at 11:48 , Török Edwin wrote:

>> In short: Performance measured on a P4 "Northwood" (no long mode,
>> plain x86) 2.4GHz. OCamlJIT2 beats OCamlJIT by a factor of 1.1 to 2.0
>> in every benchmark, and - rather surprising - was even able to beat
>> ocamlopt in the number crunching benchmark (probably an issue with
>> the x86 backend of ocamlopt).
> 
> Looks like this happens only on Pentium4: on Core2 and Xeon ocamlopt
> is still faster on almabench.unsafe, or did I miss something?

Core 2 and Xeon are x86-64, P4 is x86, so completely different architecture (with different code generator backends).

>> 
>> As mentioned by Xavier Leroy and others previously, we probably went
>> as far as we could go in the direction of JITting the byte-code
>> virtual machine, while preserving its general stack-based nature and
>> instruction set. Moving even further means translating the byte-code
>> to some intermediate form suitable for use with standard compilation
>> techniques; but as we saw earlier, in an LLVM-based prototype, the
>> compilation overhead increases dramatically and the benefit of JIT
>> compilation vanishes.
> 
> An LLVM-based backend would still be interesting for static
> compilation, where compile times don't matter much.
> Did you try comparing an LLVM-based backend with ocamlopt?
> If it is faster could some of the LLVM passes be ported to ocamlopt's
> backend?

LLVM backend for ocamlopt is a totally different story. You'd have to start with the Ulambda or the Cmm intermediate representation, while a JIT approach starts with the byte-code representation (not necessarily, but that was the case for our approach).

However, I'm not sure there would be any immediate benefit from using LLVM as code generator backend for ocamlopt, since ocamlopt already does a quite good (and fast) job. So besides probably educational or research interests, what would be the practical benefit of LLVM inside ocamlopt?

> Best regards,
> --Edwin

regards,
Benedikt