RE: [Caml-list] OCamlJIT2 vs. OCamlJIT
Erik wrote: Jon wrote: LLVM is also much better documented than ocamlopt's internals. LLVM has well over 20 full time programmers working on it. The Ocaml compiler has how many? Another reason why LLVM deserves its hype. 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
Re: [Caml-list] OCamlJIT2 vs. OCamlJIT
20 full time programmers, but if each of them has 1/40 of the skills of X. Leroy, LLVM will get only 50% of the caml native compiler performance. I'm not sure hype is correlated with value as you seem to imply but i might be wrong. This was the troll of the day. On Wed, Dec 1, 2010 at 11:58 PM, Jon Harrop jonathandeanhar...@googlemail.com wrote: Erik wrote: Jon wrote: LLVM is also much better documented than ocamlopt's internals. LLVM has well over 20 full time programmers working on it. The Ocaml compiler has how many? Another reason why LLVM deserves its hype. 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 ___ 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
RE: [Caml-list] OCamlJIT2 vs. OCamlJIT
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
real0m0.161s
user0m0.124s
sys 0m0.036s
$ time ./fib
102334155.00
real0m2.792s
user0m2.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
Re: [Caml-list] OCamlJIT2 vs. OCamlJIT
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 ___ 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
RE: [Caml-list] OCamlJIT2 vs. OCamlJIT
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. ___ 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
Re: [Caml-list] OCamlJIT2 vs. OCamlJIT
On Tue, 30 Nov 2010 09:36:07 +0100 Benedikt Meurer benedikt.meu...@googlemail.com wrote: Hello everybody, I did some final work on OCamlJIT2, and compared the result to OCamlJIT. The performance measures are presented in the following tech report (skip straight to section 4 for the performance results): http://arxiv.org/abs/1011.6223 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? 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? Best regards, --Edwin ___ 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
Re: [Caml-list] OCamlJIT2 vs. OCamlJIT
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 ___ 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
Re: [Caml-list] OCamlJIT2 vs. OCamlJIT
On Tue, Nov 30, 2010 at 11:55 AM, Benedikt Meurer benedikt.meu...@googlemail.com wrote: 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? There would be several advantages in switching to LLVM for code generation. The general idea is that if other people work on the low-level stuff, it is less work for the OCaml implementors. - more portability : while I'm not sure LLVM is ported to more platforms than OCaml right now, the LLVM community will probably port its bytecode to numerous architectures in the future; in contrast, maintining numerous backend in the OCaml compiler has a maintainance cost. In particular, cross-compilation would probably be easier. - more optimizations : the LLVM guys try to develop a wide range of optimization passes between LLVM IR and native code, while ocamlopt is mostly a non-optimising compiler. It's not clear however how much gain we could have, as OCaml has already optimized the most important parts, and a big part of the performance concerns are outside the LLVM area (data representation and GC). Still, the experience of GHC-LLVM has been quite positive, with noticeable improvements in some cases. On the other hand, it may be non-trivial to adapt LLVM to cope with the OCaml runtime, the GC in particuliar, and that would probably involve upstream changes to LLVM. LLVM is nice and trendy (though it's a shame the GNU guys, partly due to their own mistakes, are losing an important part of the FLOSS ecosystem to Apple...), but I'm personally more interested in the more theoretical projects of verified compilation toolchains, such as compcert ( http://compcert.inria.fr/ ). It's unrealistic to hope to have a completely verified ocaml-to-assembly compiler, as we would first need formal semantics for the OCaml language itself, but it is the very point : doing that kind of things forces you to have formal semantics, which is very interesting in many respects. Asking for a decent compiler was once the way to tell apart the serious languages from the insane string-fiddling script languages, but the line is blurred by the indecent amount of work injected in the optimization of those insane languages. Formal semantics will distinguish the gentlemen of the future. ___ 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
Re: [Caml-list] OCamlJIT2 vs. OCamlJIT
On Nov 30, 2010, at 9:01 AM, bluestorm wrote: On Tue, Nov 30, 2010 at 11:55 AM, Benedikt Meurer benedikt.meu...@googlemail.com wrote: There would be several advantages in switching to LLVM for code generation. The general idea is that if other people work on the low-level stuff, it is less work for the OCaml implementors. [...] LLVM is nice and trendy Yes, and it has to stop. 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 ? (though it's a shame the GNU guys, partly due to their own mistakes, are losing an important part of the FLOSS ecosystem to Apple...), but I'm personally more interested in the more theoretical projects of verified compilation toolchains, such as compcert ( http://compcert.inria.fr/ ). It's unrealistic to hope to have a completely verified ocaml-to-assembly compiler, as we would first need formal semantics for the OCaml language itself, but it is the very point : doing that kind of things forces you to have formal semantics, which is very interesting in many respects. Asking for a decent compiler was once the way to tell apart the serious languages from the insane string-fiddling script languages, but the line is blurred by the indecent amount of work injected in the optimization of those insane languages. Formal semantics will distinguish the gentlemen of the future. ___ 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 ___ 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
Re: [Caml-list] OCamlJIT2 vs. OCamlJIT
On Tue, 30 Nov 2010 18:01:28 +0100 bluestorm bluestorm.d...@gmail.com wrote: On Tue, Nov 30, 2010 at 11:55 AM, Benedikt Meurer benedikt.meu...@googlemail.com wrote: 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. I thought you already had some code to do that, but thrown it away because the JIT was too slow. Was just trying to point out that such code shouldn't be thrown away completely. Did the LLVM code you had take OCaml bytecode or Ulambda/Cmm as input? So besides probably educational or research interests, what would be the practical benefit of LLVM inside ocamlopt? There would be several advantages in switching to LLVM for code generation. The general idea is that if other people work on the low-level stuff, it is less work for the OCaml implementors. - more portability : while I'm not sure LLVM is ported to more platforms than OCaml right now, OCaml's tier 1 platforms are supported by LLVM. Ocaml's tier 2 support has more architectures than LLVM though. the LLVM community will probably port its bytecode to numerous architectures in the future; I've seen some microcontroller backends added lately, but I've also seen unmaintained and broken backends removed (IA-64 for example). in contrast, maintining numerous backend in the OCaml compiler has a maintainance cost. In particular, cross-compilation would probably be easier. - more optimizations : the LLVM guys try to develop a wide range of optimization passes between LLVM IR and native code, while ocamlopt is mostly a non-optimising compiler. It's not clear however how much gain we could have, as OCaml has already optimized the most important parts, and a big part of the performance concerns are outside the LLVM area (data representation and GC). Still, the experience of GHC-LLVM has been quite positive, with noticeable improvements in some cases. On the other hand, it may be non-trivial to adapt LLVM to cope with the OCaml runtime, the GC in particuliar, and that would probably involve upstream changes to LLVM. There is some support for emitting (assembly, not JIT) code that works with OCaml 3.10, it'd probably have to be adapted for 3.12: http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/AsmPrinter/OcamlGCPrinter.cpp http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/OcamlGC.cpp http://llvm.org/releases/2.8/docs/GarbageCollection.html LLVM is nice and trendy It'd be even nicer if it was written in OCaml, whenever I write C++ code lately it feels like I could've written the same with much less code in OCaml. If someone were to develop an LLVM backend for OCaml, I think it could coexist with ocamlopt though, allowing the user to choose which backend it wants to use. (though it's a shame the GNU guys, partly due to their own mistakes, are losing an important part of the FLOSS ecosystem to Apple...), Well there could also be a GCC backend for OCaml, but I don't know how one should get started writing one (or if it would be worth it). Best regards, --Edwin ___ 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
Re: [Caml-list] OCamlJIT2 vs. OCamlJIT
On Nov 30, 2010, at 23:06 , Jon Harrop wrote:
Because benchmarks like my HLVM ones have proven that LLVM can generate
*much* faster code than ocamlopt does.
For example, Fibonacci function over floats in HLVM with optimization passes
disabled and compilation time included in the measurement:
# let rec fib (x: float) : float =
if x 1.5 then x else fib(x - 1.0) + fib(x - 2.0);;
# fib 40.0;;
- : `Float = 1.02334e+08
Live: 0
2.48074s total; 0s suspend; 0s mark; 0s sweep
And ocamlopt without compilation time:
$ cat fib.ml
let rec fib x = if x 1.5 then x else fib(x -. 1.0) +. fib(x -. 2.0);;
fib 40.0;;
$ ocamlopt fib.ml -o fib
$ time ./fib
real0m7.811s
user0m7.808s
sys 0m0.000s
Note that HLVM's *REPL* is over 3x faster than ocamlopt-compiled OCaml.
This has nothing to do with LLVM, but is simply due to the fact that your code
does not box the float parameters/results. 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); }
So this is about data representation not code generation (using LLVM with boxed
floats would result in same/lower performance); HLVM ignores complex stuff like
polymorphism, modules, etc. (at least last time I checked), which makes code
generation almost trivial. 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.
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.
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.
Your benchmarks do not prove that LLVM generates 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.
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.
Cheers,
Jon.
regards,
Benedikt
___
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
Re: [Caml-list] OCamlJIT2 vs. OCamlJIT
On Nov 30, 2010, at 4:16 PM, Erik de Castro Lopo wrote: Jon Harrop wrote: Because benchmarks like my HLVM ones have proven that LLVM can generate *much* faster code than ocamlopt does. Until ocamlopt has an LLVM backend that is not a fair comparison. I suspect that the speed differences between your HLVM and ocamlopt have very little to do with LLVM and are almost totally due to other factors. LLVM is also much better documented than ocamlopt's internals. LLVM has well over 20 full time programmers working on it. The Ocaml compiler has how many? Microsoft has hundreds of developers working on C#, CIL, visual studio (and its integrated debugger), etc and I still find ocaml and ocamldebug superior. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ 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 ___ 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
