From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA12144 for caml-redistribution; Fri, 13 Feb 1998 20:42:33 +0100 (MET)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA17826 for <caml-list@pauillac.inria.fr>; Tue, 10 Feb 1998 21:33:14 +0100 (MET)
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35])
	by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id VAA24908;
	Tue, 10 Feb 1998 21:33:10 +0100 (MET)
Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA17817; Tue, 10 Feb 1998 21:33:10 +0100 (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)
Cc: caml-list@inria.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: weis

> 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