This is the mail archive of the
mailing list for the Cygwin project.
Re: Is multithreaded profiling on cygwin possible?
- From: Brian Ford <ford at vss dot fsi dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 7 Oct 2003 11:12:11 -0500 (CDT)
- Subject: Re: Is multithreaded profiling on cygwin possible?
peter garrone wrote:
>Brian Ford wrote:
>>peter garrone wrote:
>Sorry for the delay, or the repeat information, my original reply is
>>>If I profile my multi-threaded application, it appears that only the
>>>main thread is profiled.
>Actually, I think I was only partially correct.
>Time for the main thread is accumulated, but function calls
>are counted for all threads. This creates misleading data.
True. I primarily just use PC sampling and not call counts, so I forgot
about that part.
>>You can, however, profile other threads one at a time if you use
>>the gprof API's manually, called from the thread you want to profile. I
>>have done this, but it has been too long for me to give you specific
>>instructions. Have a look at profile.c, profile.[ch], gmon.[ch] in the
>>cygwin sources to see how its done.
>Thanks very much, this advice is a great start.
>I didnt see any way in the mcount function (winsup/cygwin/mcount.c)
>to specify a particular thread. I did see the possibility of calling
>moncontrol(1) to enable time accumulation for a particular thread,
>and searching dejanews, noticed that this is a
>recognised approach to multithreaded profiling.
Well, I might be able to devise a way to count only one thread's calls,
but it would be horrifically slow.
>>While you're there, it should be fairly trivial to create a patch that
>>at least loops through all Cygwin created pthreads in the sampler. I
>>don't know if that kind of flat profile is what you wanted, though.
>Sometimes per-thread profiling is useful, but a flat profile is what
>I want for now. Not so much for optimisation, but porting. If a thread
>is taking x% cpu on system 1 and y% cpu on system 2, then per-thread
>profiling is useful. If the whole application is running much too slow,
>then the flat profile is useful. I havent figured out how to get
>per-thread cpu on cygwin yet anyway.
Flat profiles are usually what I want also. For per thread cpu see:
><snipped dll discussion>
>You commented that dll code is difficult to profile. Would you kindly
>send me a few references to this, or keyword sets, my searching is blank.
>I am aware of the "profiling cygwin" information, and assume you mean
>extra to this.
Points 2 and 4 here are what I was referring to (note that they are
applicable to all DLLs, not just cygwin1.dll).
I couldn't seem to dig up any more detail easily.
2.) Paraphrasing, the UNIX profil call (that gprof.c is currently using),
has a contiguous flat address space model. It hashes address samples over
that space into a buffer. The starting and ending address are
automatically pulled from the executable and are in its address space.
DLLs are mapped outside this space non-contiguously.
4.) Paraphrasing, gprof doesn't know how to find and read the symbol
tables from DLLs linked into the executable. I'm not even sure if the
addresses are deterministic.
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html