Re: Profiling multithreaded C++ code
From: Richard Wallace (richard.wallace_at_specastro.com)
Date: 9 Jul 2003 14:21:25 -0700
firstname.lastname@example.org (Richard Wallace) wrote in message news:<email@example.com>...
> Hello all,
> I'm looking for some input on the best tools to use for profiling
> multithreaded C++ code developed on GNU/Linux and compiled using
> gcc-3.1. More specifically, the distro in use is RH 7.2 running
> kernel 2.4.7 with SMP. The box has dual processors.
> Some of the options I've found are
> gprof - standard GNU profiler that comes with gcc. The biggest
> problem with this is that it does not support multithreading or
> multiprocessors. There's a workaround for the multithreading support,
> but I'm not very confident in it's accuracy.
> cprof - this was something developed by Corel for profiling wine.
> AFAIK, it is no longer developed or supported. I've been able to find
> very little on it other than old posts in mailing lists and news
> tau - seems the best that I've seen so far. It's a little more
> complicated than the others and requires you to add support to the
> code (which sucks 'cause our code base is several 100's of thousands
> of lines of code). It does seem to be the most thorough and the most
> maintained of the others.
> FunctionCheck - also seems to be very good. It doesn't require any
> code modifications and was written explicitly to make up for the
> limitations of gprof. It seems as though development has been halted
> for about a year and I had some problems during compilation, but
> otherwise it seems like it will get the job done. This is the way I'm
> leaning ATM.
Scratch this one off the list for reasons below.
> These are all open source tools. I'd like to stick to that, but if
> someone has a proprietary tool that they think just blows everything
> else out of the water, I'd like to hear about it.
> Also, if anyone has any experience, good or bad, with the above
> mentioned profilers let me know.
> Thanks for your input,
> Richard Wallace
I've been testing FunctionCheck and was ready to start really diving
into and seeing if it could tell me something useful, but have already
run into a snag that I think is worth mentioning here. Many of the
programs that I will be profiling are daemon threads. They fork a
process that sits in the background and the parent process goes away.
This caused FunctionCheck to think the program was done executing when
there was still stuff going on in the background. So, on top of
threading, forking, and SMP support a profiler also needs to support
this type of daemon process.