Re: Caml performance

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

> I've been trying to compile OCaml to be instrumented with gprof.  When I do
> so, it's possible to get profile information for the ocamlrun executable
> (the interpreter), but not for any of the additional libraries (like Unix
> and Threads), presumably because they are "linked" in with the bytecode file
> that's being executed, but do not reside in the ocamlrun executable itself.

Yes, in some sense.  If you use external libraries, a special-purpose
runtime system is created and linked with your program, and the
ocamlrun executable itself is not used at all.

> Is there any way around this?  In particular, I'm trying to find out how
> much time is spent in the thread scheduler, and gprof seemed like a good way
> to find this out.

A simple way to do this is to recompile the whole OCaml distribution
with the "-p" flag.  In config/Makefile, add "-p" to the variables
BYTECCCOMPOPTS and BYTECCLINKOPTS.  Then do make clean; make all; make
install.

For good measure, also use "ocamlc -custom -ccopt -p ..." when linking
your application, to make sure "-p" is passed to the C compiler when
linking the custom runtime system.

> Secondly, I noticed that the interpreter was not compiled, by default, with
> -O on.

That is not true.  The Makefile in byterun/ adds the "-O" option itself.
Maybe a better place for that option would be in config/Makefile
itself.  But at any rate the bytecode interpreter is compiled with -O.

> By contrast, the threads library
> scheduler does have -O turned on, so it makes me think that gcc might do
> some optimizations that are not gc-safe.

Oh no, we don't let gcc mess with the GC... The GC interface is very
explicitely written down in the C code of the interpreter.  Any
optimization that would mess with the GC interface would be
semantically incorrect in a very big way.

Best regards,

- Xavier Leroy