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

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-09-28 (12:20)
From: Gerd Stolpmann <gerd@g...>
Subject: Re: [Caml-list] JIT & HLVM, LLVM

Am Sonntag, den 27.09.2009, 13:35 -0400 schrieb Edgar Friendly:
> Vincent Aravantinos wrote:
> > Hi,
> > 
> > I think what Jon means is that, with JIT, polymorphic functions can be
> > specialized at run-time
> > and allow optimizations that are not currently achieved by the Ocaml
> > native code compiler.
> > 
> > V.
> The alternative to specializing at runtime using JIT is to do it at
> compile time (/ link time) using a form of whole-program analysis.  How
> expensive would this be, and how hard would it be to still support
> separate compilation?
> And how much would the OCaml world cry if we didn't have fully-separate
> compilation? 

We don't have fully separate compilation anyway (in native mode). The
compiler can already dump an intermediate representation of functions
into .cmx files, and can use that for cross-module inlining. This
feature is optional for the user. Of course, it increases the number of
modules that need to be recompiled when something is changed.

If we keep that spirit of giving the user a choice: Of course the "Ocaml
world" would appreciate when the actual code generation can be delayed
in order to gain performance improvements by whole-program analysis.
However, for projects with several 100KLOC the compile time could be
drastically increased, and I don't think users with such large programs
would actually use that feature.


>  At the moment, and for the foreseeable future, anything
> binary is bound tightly to the compiler version, and binary distribution
> of modules seems pretty much impossible due to this and unknown other
> factors.  How much easier would the above be given the source code /
> some intermediate representation to generate specialized code with?
> 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
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714