* gprof @ 2005-09-15 10:54 Michael Trimarchi 2005-09-15 12:31 ` gprof Ken Raeburn 0 siblings, 1 reply; 5+ messages in thread From: Michael Trimarchi @ 2005-09-15 10:54 UTC (permalink / raw) To: binutils Hi all, I'd like to profile multithread application using gprof, but I cannot profile thread !!! why? Is the ITIMER signal problem? regards Michael ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gprof 2005-09-15 10:54 gprof Michael Trimarchi @ 2005-09-15 12:31 ` Ken Raeburn 2005-09-20 14:13 ` gprof Michael Trimarchi 0 siblings, 1 reply; 5+ messages in thread From: Ken Raeburn @ 2005-09-15 12:31 UTC (permalink / raw) To: Michael Trimarchi; +Cc: binutils On Sep 15, 2005, at 04:45, Michael Trimarchi wrote: > Hi all, > I'd like to profile multithread application using gprof, but I > cannot profile thread !!! why? > Is the ITIMER signal problem? > regards > Michael I've tried this before... yes, depending on the system, you may need to play some games after thread creation to start profiling in the newly created thread, such as explicitly scheduling an interrupt timer. But also, if you care about the accuracy of the results, you may need to modify the C runtime support code for profiling, which typically updates the per-function data in a manner that is not thread-safe. Unfortunately, I don't have any code to show you for either issue, right now... Ken ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gprof 2005-09-15 12:31 ` gprof Ken Raeburn @ 2005-09-20 14:13 ` Michael Trimarchi 2005-09-20 18:12 ` gprof Ken Raeburn 0 siblings, 1 reply; 5+ messages in thread From: Michael Trimarchi @ 2005-09-20 14:13 UTC (permalink / raw) To: Ken Raeburn; +Cc: binutils Ken Raeburn wrote: > On Sep 15, 2005, at 04:45, Michael Trimarchi wrote: > >> Hi all, >> I'd like to profile multithread application using gprof, but I >> cannot profile thread !!! why? >> Is the ITIMER signal problem? >> regards >> Michael > > > I've tried this before... yes, depending on the system, you may need > to play some games after thread creation to start profiling in the > newly created thread, such as explicitly scheduling an interrupt > timer. But also, if you care about the accuracy of the results, you > may need to modify the C runtime support code for profiling, which > typically updates the per-function data in a manner that is not > thread-safe. > > Unfortunately, I don't have any code to show you for either issue, > right now... > > Ken >But also, if you care about the accuracy of the results, you may need to modify the C runtime support code for >profiling, which typically updates the per-function data in a manner that is not thread-safe. may you explain more precisely this point? Regards Michael ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gprof 2005-09-20 14:13 ` gprof Michael Trimarchi @ 2005-09-20 18:12 ` Ken Raeburn 2005-09-27 10:59 ` gprof Michael Trimarchi 0 siblings, 1 reply; 5+ messages in thread From: Ken Raeburn @ 2005-09-20 18:12 UTC (permalink / raw) To: Michael Trimarchi; +Cc: binutils On Sep 20, 2005, at 06:31, Michael Trimarchi wrote: > >But also, if you care about the accuracy of the results, you may > need to modify the C runtime support code for >profiling, which > typically updates the per-function data in a manner that is not > thread-safe. > may you explain more precisely this point? > Regards > Michael With basic profiling, the runtime support code keeps track of how often the CPU program counter is in a given range of values, with fairly fine granularity. Later this table is dumped out, and (g)prof interprets it in combination with symbol information from the executable. For example, addresses XXX through YYY correspond to function A, and so many ticks at a certain frequency were counted with the PC in that range, so here's the amount of time the program spent in that function. But that may be inaccurate in multithreaded programs if the counter is implemented as read counter value N, increment value, another thread runs for a bit and changes the counter, store counter value N+1; you've just lost the change made by the other thread. For graph profiling, you also need data recorded on entry to a function indicating where the function was called from, and how many times it was called from each call site. Since you could have arbitrarily many such call sites, this is likely to involve dynamic memory allocation, walking through some data structures, etc. If it's not done just right, it might even result in crashes in multiprocessor, multithreaded situations, if you're really unlucky with the timing. I've never gotten around to modifying the support code to try to make it thread-safe. Using mutex locks would be the obvious approach, but probably kind of expensive compared to some of the atomic operations a few processors have available, or "store if another cpu or thread hasn't stored here, and set condition codes to tell me", etc. You might just get kind of lucky with the existing support code, though, your program might not crash, and the numbers might even be vaguely accurate... Ken ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gprof 2005-09-20 18:12 ` gprof Ken Raeburn @ 2005-09-27 10:59 ` Michael Trimarchi 0 siblings, 0 replies; 5+ messages in thread From: Michael Trimarchi @ 2005-09-27 10:59 UTC (permalink / raw) To: Ken Raeburn; +Cc: binutils Ken Raeburn wrote: > On Sep 20, 2005, at 06:31, Michael Trimarchi wrote: > >> >But also, if you care about the accuracy of the results, you may >> need to modify the C runtime support code for >profiling, which >> typically updates the per-function data in a manner that is not >> thread-safe. >> may you explain more precisely this point? >> Regards >> Michael > > > With basic profiling, the runtime support code keeps track of how > often the CPU program counter is in a given range of values, with > fairly fine granularity. Later this table is dumped out, and (g)prof > interprets it in combination with symbol information from the > executable. For example, addresses XXX through YYY correspond to > function A, and so many ticks at a certain frequency were counted > with the PC in that range, so here's the amount of time the program > spent in that function. But that may be inaccurate in multithreaded > programs if the counter is implemented as read counter value N, > increment value, another thread runs for a bit and changes the > counter, store counter value N+1; you've just lost the change made by > the other thread. > > For graph profiling, you also need data recorded on entry to a > function indicating where the function was called from, and how many > times it was called from each call site. Since you could have > arbitrarily many such call sites, this is likely to involve dynamic > memory allocation, walking through some data structures, etc. If > it's not done just right, it might even result in crashes in > multiprocessor, multithreaded situations, if you're really unlucky > with the timing. > > I've never gotten around to modifying the support code to try to make > it thread-safe. Using mutex locks would be the obvious approach, but > probably kind of expensive compared to some of the atomic operations > a few processors have available, or "store if another cpu or thread > hasn't stored here, and set condition codes to tell me", etc. > > You might just get kind of lucky with the existing support code, > though, your program might not crash, and the numbers might even be > vaguely accurate... > > Ken > For example, to compute the time spent inside a function foo() (starting at address X and ending at address Y) the system sample each tick looking if the program counter is between X and Y. That may be inaccurate in multithreaded programs if the accounting of a counter C is implemented as the following set of instructions: read counter value C C=C+1 store C If another thread runs for a bit interrupting the thread between 2 and 3, and that thread changes the counter, then the value stored by the interrupted thread is N+1, losing an increment. Is it ok? Regards Michael ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-09-27 9:25 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-09-15 10:54 gprof Michael Trimarchi 2005-09-15 12:31 ` gprof Ken Raeburn 2005-09-20 14:13 ` gprof Michael Trimarchi 2005-09-20 18:12 ` gprof Ken Raeburn 2005-09-27 10:59 ` gprof Michael Trimarchi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).