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 _______________________________________________ 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
