Maucci, Cyrille wrote:
Hello Jon,
I'm used to gprof on HPUX and can tell you that on HPUX when we gprof
an executable, its only works on all the objects present in the
executable but not the shared libs. Actually on HPUX, either you
choose to gprof the exe or the libs but not both. When you want both
you go to more advanced tools like Caliper.
So I don't know which platform you were running on there and if gcc's
gprof works as HPUX's gprof, but if there's the same limitation as
with HPUX's gprof, maybe this is what you've hit?
>
This was run on an AMD Opteron running Linux.
++Cyrille PS: how can you claim you have eliminated all I/Os?
Not sure what you are asking. I have deleted all input
and output statements from the program. I replace the
original input by a subroutine that generates the test
data internally. In this case, I am running the program
just to get the gprof data.
If gprof were missing 10% of the execution time, I would
shrug and say no big deal. But it's missing 70% of the
execution time, which seems to imply something
fundamentally wrong with either gprof or the way
I am using it.
Jon
-----Original Message----- From: gcc-ow...@gcc.gnu.org
[mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Jon Turner Sent: Sunday,
February 21, 2010 7:27 PM To: gcc@gcc.gnu.org Subject: Gprof can
account for less than 1/3 of execution time?!?!
I have recently encountered a gross inaccuracy in gprof that I can't
explain. Yes, I know gprof uses a sampling technique so I should not
expect a high level of precision, but the results I am getting
clearly reflect a more fundamental issue.
The program in question has been compiled with -pg for all source
code files. The time command reports 20 seconds of user time (which
is consistent with personal observation) but the gprof output
accounts for only about 6 seconds of the execution time. I have
eliminated all IO from the program, and the results remain
consistent.
Gprof is sampling the program every 10 ms, so in the observed 20
seconds of execution time, it should be taking 2000 samples, which
should be enough to avoid any grows inconsistencies.
Any ideas would be appreciated.
Jon
