From: Michael Trimarchi <trimarchi@gandalf.sssup.it>
To: Ken Raeburn <raeburn@raeburn.org>
Cc: binutils@sources.redhat.com
Subject: Re: gprof
Date: Tue, 27 Sep 2005 10:59:00 -0000 [thread overview]
Message-ID: <43390FF2.3040708@gandalf.sssup.it> (raw)
In-Reply-To: <46F43C2F-401F-4971-947E-FF27915E9CD0@raeburn.org>
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
prev parent reply other threads:[~2005-09-27 9:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 ` Michael Trimarchi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43390FF2.3040708@gandalf.sssup.it \
--to=trimarchi@gandalf.sssup.it \
--cc=binutils@sources.redhat.com \
--cc=raeburn@raeburn.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).