Benedikt wrote:
> This has nothing to do with LLVM, but is simply due to the fact that
> your code does not box the float parameters/results.
Exactly, yes.
> The following peace of C code is most probably even faster than your
> code, so what?
>
> double fib(double x) { if (x < 1.5) return x else return fib(x-1) +
> fib(x-2); }
FWIW, gcc -O2 takes longer to compile and produces slower code than HLVM
anyway:
$ time gcc -O2 fib.c -o fib
real 0m0.161s
user 0m0.124s
sys 0m0.036s
$ time ./fib
102334155.000000
real 0m2.792s
user 0m2.792s
sys 0m0.000s
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.
> 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.
> HLVM ignores
> complex stuff like polymorphism, modules, etc. (at least last time I
> checked), which makes code generation almost trivial.
OCaml ignores complex stuff like parallelism and value types (at least last
time I checked ;-). This is precisely why OCaml and HLVM complement each
other. Ideally, we would want all of this at the same time but, for now,
we'll have to settle for separate solutions.
> 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.
> A possible solution to improve ocamlopt's performance in this case
> would be to compile the recursive fib calls in a way that the
> parameter/result is passed in a floating point register (not boxed),
> and provide a wrapper for calls from outside, which unboxes the
> parameter, invokes the actual function code, and boxes the result. This
> should be doable on the Ulambda/Cmm level, so it is actually quite
> portable and completely independent of the low-level code generation
> (which is where LLVM comes into play). That way ocamlopt code will be
> as fast as the C code for this example.
Wow, I'd love to see your OCaml version that is as fast as C.
> > I have microbenchmarks where LLVM generates code over 10x faster than
> > ocamlopt (specifically, floating point code on x86) and larger
> > numerical programs that also wipe the floor with OCaml.
>
> ocamlopt's x86 floating point backend is easy to beat, as demonstrated
> in the original post. Even a simple byte-code JIT engine (which still
> boxes floating point results, etc.) is able to beat it.
Yes. Another reason to consider alternatives to ocamlopt for such
applications.
> Your benchmarks do not prove that LLVM generates faster code than
> ocamlopt.
My benchmarks show LLVM generating faster code than 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.
> > LLVM is also much better documented than ocamlopt's internals.
>
> Definitely, but LLVM replaces just the low-level stuff of ocamlopt
> (most probably starting at the Cmm level), so a lot of (undocumented)
> ocamlopt internals remain.
Sure. OCaml has a good pattern match compiler, for example.
Cheers,
Jon.
_______________________________________________
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
