On Wednesday 04 November 2009 22:21:24 Jan Kybic wrote: > > and crashes rather than performance. Moreover, I would note that the > > performant ATS code out there seems to go to *great* lengths to avoid the > > GC whenever possible, so I suspect it is extremely slow in the context of > > heavily allocating code or many short-lived values (much like HLVM). For > > This will be easy to test.
I'd like to know what you find in this respect. > > My vision for the OCaml+HLVM combo is the ability to use HLVM from your > > OCaml projects to generate and execute high performance parallel > > numerical code on-the-fly. > > So you do not plan to write a full compiler for Ocaml with HLVM > output? Correct. > That would be disappointing. There are two main problems: 1. The OCaml compiler is a very old school design that strips out essential information (e.g. untyped IRs) early in the compilation process. 2. Some obscure features of the OCaml language (e.g. polymorphic recursion) cannot be fitted into an HLVM-like infrastructure easily. > I must say, I do not have much need > to generate and execute code on the fly. I was hoping that Ocaml+HLVM would > allow me to write a more generic code without the performance penalty it > now incurs. That's the idea. > > In the meantime, you can still use HLVM to generate serial numerical code > > that is typically 2-3x faster than the equivalent OCaml code. > > Yes, but if I understand correctly, the language you can use for that > is rather restricted. Currently, yes. The main restriction is the lack of global variables. The main productivity feature is the lack of a front-end language with a decent syntax and type inference. > If I write a code like that (no polymorphic functions, no functors, no > objects), Polymorphism is easily implemented by parameterising your HLVM code definitions over the types they use. For example, HLVM's own source code already included several "polymorphic" definitions such as filling in the elements of an array of any element type. Functors and objects are a long way off. I intend to get parallelism working first and then go back and finish a simple ML front-end for HLVM. > Ocaml is already fast enough for me. And are you not better off using for > example MetaOcaml with offshoring to C? I did some experiments with MetaOCaml. Firstly, it is x86 only and not x64 which means poor floating-point performance, many times slower than HLVM's. The language itself is also very restrictive, e.g. you cannot generate pattern matches dynamically so you cannot leverage the pattern match compiler, which is a huge loss. In essence, effective use of MetaOCaml requires writing in continuation passing style which OCaml and, therefore, MetaOCaml do not handle well (closure invocations are slow in OCaml and CPS is not optimized back into anything sane). So I do not consider MetaOCaml to be a viable option for performance users. But the motivation for HLVM's JIT compilation is not metaprogramming like MetaOCaml but, rather, to build a performant REPL. -- 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
