From: Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
To: wsnyder@wsnyder.org, binutils@sourceware.org
Subject: Re: gprof errors due to loss of precision/add more digits
Date: Fri, 10 Sep 2021 10:02:21 -0700 [thread overview]
Message-ID: <d8119d7d-e842-98cc-3b71-7208fd83d4c7@oracle.com> (raw)
In-Reply-To: <8ff4550998de85d197110c43ddb88ee6@wsnyder.org>
On 9/10/21 4:26 AM, wsnyder@wsnyder.org wrote:
> As background I support Verilator, which generates applications where there are often 10K+ functions. These create a relatively flat profile that runs through gprof. The gprof report is then post-analyzed to combine some of the 10K+ results into 10-ish groupings. What users are finding is that the sum of percentages of the groupings in some cases is only accounting for roughly 40% of the program time.
Is the sum of the absolute time wrong too ?
If not, it means the calculation of percentages is wrong for group. It
should not be a sum of percentages.
>
> This due to the gprof report. In that report, the sum of all of the various function's percentage column sums to only about 40%. This is because there are many functions which print as in report as "0.00%", but really the number behind that might be up to e.g. "0.004%", and if we could sum all of those lost-to-truncation values we'd get 60% of the total program time.
>
> If I edit gprof's hist.c to print e.g. 9 digits of precision then all of the "missing" time is now accounted for, proving it is a rounding issue.
>
> 1. Is there any existing way to have gprof print sym->hist_time, and/or more precision in the time or percentage columns, to avoid this loss of data due to this precision issue?
>
> 2. Would a patch to add a gprof flag to print sym->hist.time e.g. 9 digits of precision be potentially accepted?
>
> 3. Any other suggestions?
>
> Thanks
>
> P.S. Saw a thread about gprofng being under development - suggest that also (optionally?) print many more digits!
>
next prev parent reply other threads:[~2021-09-10 17:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-10 11:26 wsnyder
2021-09-10 13:07 ` Ruud van der Pas
2021-09-10 17:02 ` Vladimir Mezentsev [this message]
2021-09-12 22:52 ` wsnyder
2021-09-13 21:48 ` Ruud van der Pas
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=d8119d7d-e842-98cc-3b71-7208fd83d4c7@oracle.com \
--to=vladimir.mezentsev@oracle.com \
--cc=binutils@sourceware.org \
--cc=wsnyder@wsnyder.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).