Re: [Caml-list] native code optimization priorities

[Xavier Leroy <xavier.leroy@inria.fr>]

> However, I have a bunch of small things I'd like to implement (or
> see implemented) for making native numerical code faster.  This is
> primarily for my video game work, but the kinds of things I have in
> mind will also help any numerically intensive application.  So, here
> are my questions:
> 
> 0.  How important is optimization to the team?

Generating efficient machine code has always been an important aspect
of OCaml, and I spent quite a bit of work on this at the beginning of
the OCaml development (95-97).  Nowadays, we are largely satisfied
with the performances of the generated code, and get very few requests
for improving it, so this aspect of the OCaml implementation has
received little attention recently.

Also, I believe we've hit the point of diminishing returns: the major
optimizations (that lead to significant speedups on many programs) are
already in the ocamlopt compiler; further optimizations would (I
believe) result in tiny speedups (less than 5%) or be extremely
specific to a couple of test programs.

> 1.  Are there any new (big or small) optimizations planned or in the works?

Not really.  Like other members of the OCaml development teams, I have
vague ideas about things that could be done, e.g. a Pentium-4 back-end
that would use SSE2 registers for floating-point, but this is all
low priority.

Of course, we are committed to track changes in dominant processor
architectures; for instance, if the IA64 becomes widespread (heavens
forbid), some effort will have to be invested in cross-basic-block
instruction scheduling, if-conversion, and perhaps exploitation of
advanced loads.  But the fact is that computer architectures viewed
from the compiler writer's standpoint haven't changed significantly in
the last 5 years: these hardware guys do such a good job of cranking
out better and faster processors that require no change in the compiler...

> 2.  What's the relative priority of new features versus compiler
> optimizations?

As I said above, the demand for more optimizations is low.  Moreover,
advanced compiler optimizations require a lot of implementation and
testing work.

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

I use intensively the small benchmark suite available at:
        http://camlcvs.inria.fr/cgi-bin/cvsweb.cgi/ocaml/test/
These are mostly small benchmarks, but some of them (KB, fft, nucleic)
predict fairly well the performances of bigger applications.
The ICFP programming contest entries of the last three years have also
been used as benchmarks several times.  Finally, the Coq theorem
prover stresses quite well the compiler and runtime system as far as
symbolic processing is concerned.

> 4.  Are numerical operations an important area for ocaml to succeed?

Although ML is historically rooted in symbolic processing, I did quite
a bit of work on the compiler to achieve decent floating-point performance.
Still, symbolic processing is OCaml's bread-and-butter, and takes
precedence over floating-point performance.

>  Put another way, if an optimization helps numerical code but does
>  not help other code (or even slightly hurts it), how would that patch
>  be received?

Does not help: OK.  Slightly hurts it: that might be a problem.  OCaml
contains one instance of this: float arrays are special-cased in a way
that improves tremendously the performance of floating-point code,
but slows down polymorphic code operating on arrays.  I still think
this was an acceptable trade-off, but not everyone agrees.

Some of my earlier work on type-directed compilation (the Gallium
experimental compiler) was abandoned because while it improved the
performance of floating-point and integer computations, it slowed down
the garbage collector too much, causing pure symbolic processing to
take an unacceptable performance hit.

> What about command line options for optimization (of which there
> very few now) to offset this affect?

Only if we absolutely must.  The problem with having lots of compiler
flags is that it makes testing the compiler much harder -- in
principle, all combinations of flags should be tested...

> 5.  How does the team feel about optimizations added to the x86 code
> generator that don't help other platforms?

Fine with me.  Like all compiler writers, I hate the IA32
architecture, but that's what everyone uses these days.  The ocamlopt
back-end already contains quite a bit of IA32-specific code (in the
instruction selection phase, for instance).

Hope this answers your questions.

- Xavier Leroy
-------------------
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