Re: [Caml-list] Ocaml and C--

[reig@dcs.gla.ac.uk]

Norman Ramsey wrote:
> 
>  > Supposing that QC-- will deliver it promises...
>  > will Ocaml switch to target C-- or will Ocaml continue to
>  > natively target the usual architectures (x86, Alpha, Sparc, ia64,
>  > x86-64...)?
> 
> It's way too early to ask anyone to make this decision, because C-- is
> a long way away from being good enough and reliable enough to support
> a production compiler.  Having said that, Fermin Reig has been doing
> some very interesting experiments with OCaml and C--, which I hope he
> will comment on here.

I have modified ocamlopt to emit C-- instead of Mach code (Mach is
ocamlopt's intermediate language of abstract machine
instructions). The C-- backend produces code that is slightly slower
than the native ocamlopt backend (alpha/linux). I have identified
several reasons for this slowdown:

1. Memory allocation.

ocamlopt combines several allocations in the same basic block into one
that requests a larger chunk of memory. This is done in the Mach
internal representation, so we lose this optimization in the C--
backend. OCaml programs contain many individual allocations and each
allocation translates into a conditional branch, which is not cheap in
modern RISC proessors.

2. Instruction scheduling

ocamlopt does better instruction scheduling inside basic blocks than
the C-- compiler.

3. Garbage collection

The C-- compiler reports GC roots to the garbage collector that may
not be live at the point of the collection (the collector is still
type-accurate, but not liveness-accurate). This prevents some garbage
from being reclaimed and can make each collection to take longer.

Other minor issues that may slowdown garbage collection (email me if
you want to know the details).

4. Exception handling

It's a little bit more costly via C--, but so little that it should go
unnoticed (though I haven't measured it).


Fermin

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr