Re: Caml performance

From: Xavier Leroy (Xavier.Leroy@inria.fr)
Date: Tue Feb 10 1998 - 21:33:10 MET


From: Xavier Leroy <Xavier.Leroy@inria.fr>
Message-Id: <199802102033.VAA17817@pauillac.inria.fr>
Subject: Re: Caml performance
In-Reply-To: <199802011548.KAA12442@codex.cis.upenn.edu> from Michael Hicks at "Feb 1, 98 10:48:15 am"
To: mwh@dsl.cis.upenn.edu (Michael Hicks)
Date: Tue, 10 Feb 1998 21:33:10 +0100 (MET)

> 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



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:13 MET