[Caml-list] Obsessed by speed

[William Chesters <williamc@paneris.org>]

Mattias Waldau writes:
 > In the FAQ, I can read an estimation on how expensive different operations
 > in ocamlopt are.
 > 
 > I have some further questions:
 > 1. If I define Array.iter + a function that uses it,
 >    will ocamlopt combine these two functions two one?
 >    (I looked in the assembler code, but it seemed as
 >     ocamlopt didn't combine them)

That's been my experience too---definitely it would be nice to have!

 > 3. Would ocamlopt benefit from a peephole optimizer of
 >    the assembler code? Or is the assembler code already
 >    optimal?

I have generally found the backend to be very good indeed at the
assembler level.  Sometimes it gets things handed down to it from the
intermediate level (e.g. less-than-100% unboxing) which it couldn't
reasonably be expected to fix.  It's so much better than backends like
JDK, ghc, ... it isn't funny.

 > 4. What is unboxed and what isn't?

Integers are always unboxed anyway (they are tagged with a low 1 and
the arithmetic done on them is warped to accomodate it!).

Floats seem to be unboxed very well within an expression.  Float loop
variables in for-loops (sadly not tail-recursive expressions) stay
unboxed and indeed in registers, _provided_ that they are stored in
monomorphic records that are known at a high level to be
float-only---so not float ref (!!!).  Define e.g. type floatref = {
it: float }, works much better.

To a reasonable extent, whole objects are "unboxed" too, i.e. tuples
and records which are simply passed to functions which immediately
deconstruct them are elided and the components become available for
storing in registers.  I don't know to what extent this happens in
other situations but it is very helpful.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr