The implementation has some interesting properties:
The GC is written entirely in HLVM's own intermediate language.
When a new type is defined a new function to traverse that type is JIT
compiled. So code for the GC is generated on-the-fly.
The GC is very simple and uses a shadow stack to track roots and an
allocated list that stores all heap allocated locations and their mark bit.
When the GC gets involved, performance is currently awful. Two simple
optimizations will go a long way to curing this: touch the shadow stack only
when necessary, and do something cleverer than the current linear lookup (!)
of allocated pointers in the GC.
When the heap is deep the current GC stack overflows because it is not tail
recursive. This is easily fixed.
I have applied to the OCaml Forge to create a new project for HLVM where I
will upload my initial prototype. Just as soon as my French gets good enough
to understand this automated e-mail... ;-)
Dr Jon Harrop, Flying Frog Consultancy Ltd.
Caml-list mailing list. Subscription management:
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
The OCaml Forge has kindly accepted to host the HLVM project:
If you are interested in following, discussing or contributing to this project
please join me on the hlvm-list:
There's no license information in the repository or in any of the
files. Without that, technically even looking at the software is
dangerous, and it can't be copied. What's the license for this?
> The OCaml Forge has kindly accepted to host the HLVM project:
Am I the only one who VASTLY prefers the clean, uncluttered and easy
to use GitHub interface to the *Forge one?
Mac, C++, OCaml
On 08-03-2009, Joel Reymont <joe...@gmail.com> wrote:
> On Mar 8, 2009, at 2:45 AM, Jon Harrop wrote:
>> The OCaml Forge has kindly accepted to host the HLVM project:
> Am I the only one who VASTLY prefers the clean, uncluttered and easy
> to use GitHub interface to the *Forge one?
AFAIK, Github host only git repository. Forge.ocamlcore.org not only
host repository but also mailing-list, bug tracker and file section.
Moreover, hlvm is a SVN repository which makes github a non-sense for
We do also have a git repository for projects (git.ocamlcore.org) though
not as shiny as github.
If you do prefer github for your repository, you can of course host BTS,
mailing-list and files section on forge.ocamlcore.org and your git
repository on github. There is nothing that prevent it.
The purpose of forge.ocamlcore.org is to have a more central point for
OCaml projects, giving visibility to OCaml community
Sylvain Le Gall
Looking more closely, it seems there is Downloads/Wiki and some stats.
Though it remains git-centric and not particularly OCaml related (only 2
repository seems to be related to OCaml).
Github seems to have evolve since last time I take a look at it...
(toward more *forge features)
> If you do prefer github for your repository, you can of course host BTS,
> mailing-list and files section on forge.ocamlcore.org and your git
> repository on github. There is nothing that prevent it.
> The purpose of forge.ocamlcore.org is to have a more central point for
> OCaml projects, giving visibility to OCaml community
This point is still very important, giving visibility to OCaml community
is to my mind the best thing to do. Having multiple project hosted
everywhere just "dilute" OCaml in more mainstream language projects.
I haven't tried GitHub but the OCamlForge is really rather cool.
I think "dangerous" is overly excessive. ;-)
I've gone for a 2-clause BSD license which is listed on the Forge and the
document is now in the SVN repo as well.
I've also classified this as an alpha release. Once I've fixed the bugs that I
know about I'll move it up into a beta release.
Hello. Just out of curiosity:
I recall reading that one of your priorities for HLVM is
performance of numerical code. Does it mean that you expect numerical
code to run faster than natively compiled (with ocamlopt) Ocaml?
Do you have any experiments so far to support this?
I am doing large scale numerical calculations in Ocaml and performance
is always an issue for me.
Thank you for your effort.
Jan Kybic <ky...@fel.cvut.cz> tel. +420 2 2435 5721
http://cmp.felk.cvut.cz/~kybic ICQ 200569450
HLVM aspires to provide the following benefits over OCaml:
High performance numerics (often 2-4x faster than OCaml on x86).
High performance polymorphism: polymorphic definitions are instantiated for
More numeric types (float32, complexes, low-dimensional vectors and
More optimizations for the benefit of numerical computing: common
subexpression elimination, hoisting of loop invariants, inlining of function
arguments to higher-order functions.
Faster and easier FFI for external libraries like FFTW and LAPACK.
Dynamic capabilities such as generic printing, hashing, comparison,
serialization and run-time type information.
Community led development: you can contribute to the open source HLVM code
Commerce friendly design so it will be viable for you to buy and sell
libraries written for HLVM.
A common language run-time so you can safely consume and produce libraries
written in any languages with implementations that target HLVM.
> Does it mean that you expect numerical code to run faster than natively
> compiled (with ocamlopt) Ocaml?
Absolutely. Most numerical code already runs a lot faster in HLVM than it does
in ocamlopt if you disable GC in any inner loops that act upon arrays. In the
future, I expect HLVM to be a lot faster still because it will generate SSE
instructions (using LLVM's vector intrinsics) and perform many optimizations
of its own (such as hoisting the GC code automatically).
> Do you have any experiments so far to support this?
Yes. The "test.ml" file from the HLVM subversion repository contains over 500
lines of test code that includes a few simple benchmarks. Here is a
comparison of the performance of ordinary OCaml with the best performance I
have been able to obtain using HLVM:
Float Fibonacci (recursive floating point functions)
HLVM: 1.74s 3.5x faster than ocamlopt
Mandelbrot (complex arithmetic)
HLVM: 1.89s 2.3x faster than ocamlopt
Sieve of Eratosthenes (int arrays)
OCaml: 14.9s (had to use big arrays)
HLVM: 7.05s 2.1x faster than ocamlopt
As you can see HLVM is already generating much faster code than ocamlopt. Note
that the OCaml code can be improved (e.g. by avoiding OCaml's complex number
type) but the point is that idiomatic code is much faster with HLVM.
> I am doing large scale numerical calculations in Ocaml and performance
> is always an issue for me.
A lot of people have adopted OCaml for number crunching and string munging
(bioinformatics). Although ocamlopt is an excellent compiler, HLVM has shown
that it is possible to do much better still. I hope HLVM will form the
backbone of an OCaml variant designed specifically for technical computing.
I forgot the second most important goal (!):
Easy and efficient parallelism to leverage multicores.
Thanks Jon, that's excellent news.
On Mar 9, 4:47 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> > HLVM aspires to provide the following benefits over OCaml:
> I forgot the second most important goal (!):
> Easy and efficient parallelism to leverage multicores.
If you've already discussed this somewhere and I missed it, I
How might coders of OCaml-on-HLVM code for parallelism? Using
something like JoCaml, perhaps?
When you talk about HLVM vs OCaml are you talking about the
implementation or the language?
I'm guessing the former. You're comparing the HLVM performance vs
Don't you need to implement OCaml (the language) to run on HLVM? How
much of OCaml can you currently parse?
That's nice as the ghc/haskell folks currently way ahead in that
BTW: are you adding some specialized extensions to your implementation
of OCaml to handle parallelism?
I have just updated HLVM's GC to use a hash table instead of a linear search
of the allocated list. This brings GC time down from O(n^2) to amortized
O(n). In practice, the benchmarks are up to 100x faster than they were and,
in the worst case, HLVM is now only 5x slower than OCaml.
Keep up the good work.
I'm still a bit worried about that 60MB runtime though ...
Are you looking into trace trees for JIT?
I was wrong about that actually. It was only 60Mb because I had compiled LLVM
with debugging on. Now that I have LLVM 2.5 compiled for release my HLVM
executable is under 10Mb. Still large but I'm happy with that.
> Are you looking into trace trees for JIT?
You mean for the code fed into HLVM? No, not yet. We need more code to feed
into it before that will become interesting!