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
[Caml-list] native code optimization priorities
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-10-31 (08:49)
From: Fabrice Le Fessant <fabrice.le_fessant@i...>
Subject: Re: [Caml-list] native code optimization priorities

I'm not part of the Ocaml devel team, but as an "old" ocaml user, I would

>  0.  How important is optimization to the team?
>  2.  What's the relative priority of new features versus compiler
>  optimizations?

Optimizations are welcome, if they don't complexify too much the compiler.

>  3.  Is there some kind of standard suite of test applications the
>  3.  caml team runs to figure out whether an optimization is worth
>  3.  it to include?

Look at the CVS version of ocaml, there are test directories I
think. Coq compilation is often used for evaluating optimizations.

>  4.  Are numerical operations an important area for ocaml to
>  4.  succeed?  Put another way, if an optimization helps numerical
>  4.  code but does not help other code (or even slightly hurts it),
>  4.  how would that patch be received?  What about command line
>  4.  options for optimization (of which there very few now) to
>  4.  offset this affect?

Most current users look more interested in "symbolic" computations,
than in "numerical" applications. However, this might change if you
add such an optimization patch. But, if your patch degrades "symbolic"
performances, you MUST ADD AN OPTION to trigger it ONLY on numerical

Notice that, as discussed before on this mailing-list, I would welcome
such a patch in the CDK.
>  5.  How does the team feel about optimizations added to the x86
>  5.  code generator that don't help other platforms?

x86 optimization is better than nothing.

Finally, I would say it might be interesting to have an optional pass
in the compiler, where user-contributed optimizations might be added.
Then, there would be some space for an independant project, something
like ocaml-opts.sourceforge.net that would develop this pass.


Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr