Re: [Caml-list] Google summer of Code proposal

[Jon Harrop <jon@ffconsultancy.com>]

On Monday 30 March 2009 16:56:37 Joel Reymont wrote:
> There's a nice discussion of LLVM in the context of Alice ML here:
>
> http://lambda-the-ultimate.org/node/440
>
> I'm told that not much has changed since.

Whoever told you that was wrong: a lot has changed in LLVM over the past five 
years. Indeed, it is one of the most rapidly advancing open source projects 
in existence thanks to extensive contributions from the likes of Apple and 
Google.

LLVM has long since had full support for tail calls. See the "tco" example in 
the "test.ml" file of HLVM for an example. I tested tail calls in LLVM 
extensively before choosing to build upon it. I have found and worked around 
some minor bugs in their TCO implementation but Arnold Schwaighofer just 
committed a fix that will be in LLVM 2.6.

The toy Scheme implementation that was in LLVM five years ago has long since 
been overshadowed by full-blown FPL implementations like the Pure language:

  http://pure-lang.sourceforge.net/

I don't understand Anton van Straaten's other complaint about the lack of 
closures. They are trivial to implement. Again, look at the examples in HLVM 
(although they are hand-coded because we don't have lambda lifting yet).

Moreover, LLVM offers huge advantages:

. LLVM-generated code on x86 is often several times faster and can be up to an 
order of magnitude faster than any existing FPL implementation. Moreover, 
LLVM can JIT compile, making it trivial to outperform interpreted languages 
like OCaml's current top-level. See HLVM's preliminary performance results, 
for example:

http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-04.html

. LLVM generates code very quickly, rivalling ocamlopt's compile times.

. SSE and atomic instructions for high-performance numerics and 
parallelism/concurrency.

. Mature and easy-to-use API with native OCaml bindings.

. Substantial friendly community who not only explain things but fix them for 
you quickly.

. Commercially viable: LLVM is already shipping in products.

LLVM does have some disadvantages:

. LLVM's JIT compiler is not multicore capable (but what FPL implementations 
are?).

. LLVM does not bundle a reusable high-performance concurrent garbage 
collector (but what standalone FPLs do?).

. LLVM's GC API is experimental so if you want a specialized run-time (e.g. 
optimized specifically for symbolics) you have to write it yourself.

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