Re: [Caml-list] OCamlJIT2 vs. OCamlJIT

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

On Dec 1, 2010, at 15:11 , Jon Harrop wrote:

> If you're asking what the advantages of using LLVM over generating C code
> are, I'd say functionality like more numeric types, tail calls and JIT
> compilation come top but also the fact that LLVM bundles nice OCaml bindings
> and makes it easy to generate fast code. Also, I have other examples (e.g.
> the random number generator from the SciMark2 benchmark) where LLVM can
> generate code that runs 2x faster than anything I've been able to get out of
> GCC.

LLVM sure does better as an intermediate language than C does, no question. But that wasn't my point in this example.

>> So this is about data representation not code generation (using LLVM
>> with boxed floats would result in same/lower performance);
> 
> Yes. LLVM lets you choose your own data representation and applications like
> numerics can benefit enormously from that. All the more reason to use LLVM.

As does assembler, so even more reasons to emit assembler?

>> The literature
>> includes various solutions to implement stuff like ML polymorphism:
>> tagged integers/boxed floats/objects is just one solution, not
>> necessarily the best; but examples that simply ignore the complex
>> stuff, and therefore deliver better performance don't really help to
>> make progress.
> 
> Right. Reified generics can be a much better solution for performance,
> particularly when combined with value types, and something else that
> ocamlopt cannot express but HLVM can.

So this is an area to work on within ocamlopt.

>> Instead you proved that OCaml's floating point representation
>> comes at a cost for number crunching applications (which is obvious).
>> Use the same data representation with LLVM (or C) and you'll notice
>> that the performance is the same (most likely worse) compared to
>> ocamlopt.
> 
> You are saying is that LLVM might not be faster if it were also afflicted
> with ocamlopt's design, which is unproductive speculation. The point is that
> LLVM and HLVM are not constrained by those design decisions as OCaml is, so
> you can use them to generate much faster code.

We are talking about using LLVM within the OCaml compiler, so we have to talk about OCaml, not HLVM or anything else.

Don't get me wrong, I'm curious to see an LLVM backend for ocamlopt, especially since that way we would get a native top-level for free (at least for the JIT capable LLVM targets). But I doubt that LLVM will make a noticeable difference (except for probably reduced number of target specific code), since it will be faced with the same data representation used right now and LLVM will not be able to optimize much (assuming the ocamlopt higher level optimizations were already applied).

What you are talking about is replacing several design decisions within OCaml (which have nothing to do with the low-level code generator); this might be a good idea, and may indeed improve generated code. I don't know the opinion of the OCaml core developers, but from my POV, this sounds like an interesting challenge; however getting beyond a simplified proof-of-concept requires a lot of hard work.

> Cheers,
> Jon.

greets,
Benedikt