Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Tue, 7 Oct 2003 11:12:11 -0500 (CDT) From: Brian Ford X-X-Sender: ford AT eos To: cygwin AT cygwin DOT com Subject: Re: Is multithreaded profiling on cygwin possible? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: > >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/