English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
AST versus Ocaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-11-04 (23:15)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] AST versus Ocaml
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?


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