This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
>lost.
>
No problem.

>>>If I profile my multi-threaded application, it appears that only the
>>>main thread is profiled.
>>>
>>Currently, yes.
>>
>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.

>>PTC
>>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).

http://sources.redhat.com/ml/cygwin-patches/2002-q2/msg00206.html

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.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]