[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Xavier Leroy <Xavier.Leroy@i...> |
| Subject: | Re: Caml performance |
> 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