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
OCamlJit 2.0
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-11-19 (19:16)
From: Benedikt Meurer <benedikt.meurer@g...>
Subject: Re: [Caml-list] Re: Native toplevel?

On Nov 19, 2010, at 11:02 , Fabrice Le Fessant wrote:

> Benedikt Meurer wrote, On 11/19/2010 06:29 AM:
>> This is indeed very interesting. I haven't thought of the native top-level. I haven't done any measurements yet, but from my experience with ocamlopt, I know that the optimizing native compiler is somewhat slower than the byte-code compiler. I doubt that this is related solely to the external as/ld invocations, so there's certainly more work to do than just replacing the calls to as/ld with an in-process assembler/linker.
> Indeed, there are some more passes in ocamlopt than in ocamlc, but I
> think that most of the time is spent in allocating registers and
> generating the assembler file and calling the assembler. As Alain said,
> we already have the inline assembler, so the next step would be to
> improve register allocation, either by spilling more variables to avoid
> the quadratic behavior of graph coloring, either by using some linear
> scan algorithm (for example, the one of HotSpot).

Using the linear scan algorithm with ocamlopt might be a good idea, due to the structure of the generated code, linear scan should give results close to that of the graph coloring algorithm for the generated native code. I'll see if I can hire some students to evaluate an implementation of linear scan for ocamlopt.

> --Fabrice