RE: [Caml-list] OCamlJIT2 vs. OCamlJIT

[Jon Harrop <jonathandeanharrop@googlemail.com>]

Benedikt wrote:
> 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.

I think we are talking at cross purposes. My post was to explain some of the
many benefits of LLVM in response to Yoann's statement:

  "I don't understand why there is so much hype around LLVM. Why would you
think something written in C++ would be far better than the ocaml code we
have in the ocamlopt compiler?"

I was not just talking about porting ocamlopt to LLVM but more generally
about the advantages of using LLVM from OCaml in any way.

> >> 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?

LLVM makes it a *lot* easier to generate efficient code, of course.

> >> 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.

If you can add value types and reified generics to ocamlopt and get them
accepted that would be great.

> > 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.

I was talking more generally about the benefits of LLVM in response to
Yoann's statement about the hype surrounding LLVM. HLVM demonstrates some of
the things a next-generation ocamlopt might be capable of.

> 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).

Absolutely. 

> What you are talking about is replacing several design decisions within
> OCaml (which have nothing to do with the low-level code generator);

Except that those design decisions have a huge effect on the optimizations
LLVM will do (if it is your code gen).

> this might be a good idea, and may indeed improve generated code.

HLVM's benchmark results would certainly seem to indicate that, yes.

> 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.

Yes. At the end of the day, the performance gains that can be obtained by
bringing the GC up to date already dwarf all of these other effects so a new
GC is surely the highest priority. 

This begs a couple of questions:

* How dependent is OCaml bytecode on the data representation and GC?

* Could you write an OCaml bytecode interpreter in OCaml?

Perhaps we could write a multicore friendly OCamlJIT3. :-)

Cheers,
Jon.