Re: [Caml-list] Odd performance result with HLVM

[Jon Harrop <jon@ffconsultancy.com>]

On Saturday 28 February 2009 20:18:40 Kuba Ober wrote:
> You didn't let us in on how it really works. You said "high-level
> virtual machine
> built upon LLVM and written in OCaml". LLVM means too many things to be
> able to decipher what you mean, and your statement is too general.

I'm referring to my HLVM project that I described here:

http://flyingfrogblog.blogspot.com/2008/12/building-better-future-high-level.html

That is built upon the Low-Level Virtual Machine here:

http://llvm.org

Basically, my idea is to build a better VM for OCaml-like languages. My work 
is still at a very early stage of development but the results are already 
promising: faster than ocamlopt on all of my benchmarks and several times 
faster on some numerical benchmarks.

There are really two major advantages over the current ocamlopt design and 
both stem from the use of JIT compilation:

. Run-time types allow per-type functions like generic pretty printers and 
comparison.

. Monomorphisation during JIT compilation completely removes the performance 
cost of polymorphism, e.g. floats, tuples and records are never boxed.

Algebraic datatypes were the latest addition and I expected them to be very 
slow because I am calling thread-safe malloc every time one is created. 
However, a simple benchmark that creates and folds over a huge list actually 
runs faster on my HLVM than it does in OCaml.

> I'm assuming, but that's forced, so don't shoot if I make an asinus
> out of myself ;)
>
> So, it's a VM and it runs native jit-ted code like say .net would. So
> presumably you
> have some OCaml code that then invokes jit and some native functions
> to dispatch
> to jit-ted code?

Yes.

> Do you interpret any bytecode, or always compile?

Always compile.

> Do  
> you even
> have to have any OCaml code running in the process where the jit-ted
> code runs in?

I believe the OCaml bindings to LLVM JIT compile a function, get a pointer to 
it and call into that function from the current thread. So there is no 
process separation.

> I presume you use the LLVM infrastructure to do the jit-ting, but
> without knowing
> exactly what code runs in the process space of the application, it's
> hard to tell
> what's going on.

You just gave me another idea: use LLVM to compile the same IR code to a 
standalone executable and benchmark that. I'll get back to you...

> There's no floating point state to change that would slow things up
> that much.
> At least I have never seen anything like that.

That's what I thought.

> Maybe the FP exceptions are being fired somehow?

Maybe something like that. I have no idea.

This definitely only affects float performance so it is not a difference in 
the efficiency of calling into JIT compiled code from OCaml bytecode or 
native code.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e