Re: [Caml-list] native code optimization priorities

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

> Just out of curiosity: what do you as a compiler developer dislike
> about the IA64-architecture so much that you said "heavens forbid"? Not
> that I have any opinion on this - it's only interesting to learn about
> shortcomings of the new architecture. Do you think its features are not
> useful for getting even more efficient code out of ocamlopt? Is it just
> too complicated a design?

This is getting off-topic for this list, but briefly: the IA64
architecture is baroque.  It is very complex, provides lots of dubious
features (register windows, hardware support for software pipelining,
several kinds of load-store speculation), yet lacks some very basic
things (such as indirect addressing with immediate displacement).  We
are very far from the elegance and minimality of classic RISCs such as
the Alpha.  All these fancy features seem targeted to high-performance
Fortran; it is unclear how to exploit them for C, let alone for Caml.

Moreover, it relies on the compiler to make instruction parallelism
explicit.  I believe this is a bad idea compared with what everyone
else is doing these days, i.e. discovers instruction parallelism at
run-time, in the chip (out-of-order execution).

Finally, the first silicon implementation (Itanium) is very late, very
expensive, and slower than a $150 Pentium or Athlon for integer code
(floating-point performance is excellent, though).  Future
implementation will probably be better, but still this might indicate
something wrong in the design of the architecture.

As for using the IA64 features in ocamlopt-generated code, it might be
possible to make good use of predication (conditional instructions)
for short conditional sequences, and of load speculation (exploiting
the fact that a load from an immutable OCaml block cannot interfere
with any store).  However, both features need new optimization passes
that include quite sophisticated heuristics (neither predication nor
load speculation are always a win, both can also swamp processor
resources with useless instructions).

- 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