|
From: David <sho...@gm...> - 2010-02-16 17:54:17
|
Hi Valgrind expert,
I am confused about the Ir count before the "=>" symbol in the annotated
source code. For example, if the annotated source code looks like
function F ()
{
...
#A => subroutine SR (#Bx)
...
#C => subroutine SR (#Dx)
...
}
where #A - #D are four numbers and SR in two lines is the same subroutine.
It seems that the numbers in the parenthesis ending with 'X' (#B and #D) is
the exact subroutine invoking counts but the numbers before the "=>" symbol
can not be treated as the exact Ir count for the corresponding invoking.
Some times the bigger number of #A and #C corresponds to the Inclusive Ir
count of the function SR. Sometimes neither of them corresponds to the
Inclusive Ir count of the function SR and the sum of them is obvious beyond
that Inclusive Ir count. How should I understand the Ir count before the
"=>" symbol? Where can I find more detailed information about the annotated
source code? Any suggestion is appreciated!
Peace,
-David
|
|
From: Josef W. <Jos...@gm...> - 2010-02-16 20:56:25
|
Hi,
On Tuesday 16 February 2010, David wrote:
> I am confused about the Ir count before the "=>" symbol in the annotated
> source code. For example, if the annotated source code looks like
>
> function F ()
> {
> ...
> #A => subroutine SR (#Bx)
> ...
> #C => subroutine SR (#Dx)
> ...
> }
>
> where #A - #D are four numbers and SR in two lines is the same subroutine.
I suppose you talk about the output of "callgrind_annotate --auto=yes" on a
output of callgrind run with "--collect-jumps=yes" ?
> It seems that the numbers in the parenthesis ending with 'X' (#B and #D) is
> the exact subroutine invoking counts but the numbers before the "=>" symbol
> can not be treated as the exact Ir count for the corresponding invoking.
Hmm. It looks like it should be the exact Ir inclusive cost of this invocation
instance. If it is not, it seems to be a bug.
> Some times the bigger number of #A and #C corresponds to the Inclusive Ir
> count of the function SR. Sometimes neither of them corresponds to the
> Inclusive Ir count of the function SR and the sum of them is obvious beyond
> that Inclusive Ir count.
That sounds very wrong.
Can you file a bug report?
It would be good to provide a small test program with the wrong output you get.
Thanks!
Josef
> How should I understand the Ir count before the
> "=>" symbol? Where can I find more detailed information about the annotated
> source code? Any suggestion is appreciated!
>
>
> Peace,
> -David
>
|
|
From: David <sho...@gm...> - 2010-02-16 22:14:36
|
Hello Josef,
It is very nice to talk with the Valgrind Developer here. I am so lucky. :-)
On Tue, Feb 16, 2010 at 12:56 PM, Josef Weidendorfer <
Jos...@gm...> wrote:
> Hi,
>
> On Tuesday 16 February 2010, David wrote:
> > I am confused about the Ir count before the "=>" symbol in the annotated
> > source code. For example, if the annotated source code looks like
> >
> > function F ()
> > {
> > ...
> > #A => subroutine SR (#Bx)
> > ...
> > #C => subroutine SR (#Dx)
> > ...
> > }
> >
> > where #A - #D are four numbers and SR in two lines is the same
> subroutine.
>
> I suppose you talk about the output of "callgrind_annotate --auto=yes" on a
> output of callgrind run with "--collect-jumps=yes" ?
>
Actually I am talking about the output of "callgrind_annotate --auto=yes /
callgrind_annotate --auto=yes --inclusive=yes" on a output of callgrind run
without "--collect-jumps=yes" ("valgrind --tool=callgrind" only).
Thank you for your reminder. I will check with the option
--collect-jumps=yes after this discussion.
>
> > It seems that the numbers in the parenthesis ending with 'X' (#B and #D)
> is
> > the exact subroutine invoking counts but the numbers before the "=>"
> symbol
> > can not be treated as the exact Ir count for the corresponding invoking.
>
> Hmm. It looks like it should be the exact Ir inclusive cost of this
> invocation
> instance. If it is not, it seems to be a bug.
>
My assumptions are: (1) #B and #D should be the exact subroutine invoking
counts for that line and (2) both #A and #C should be the exact Ir inclusive
cost of this invocation instance which could be found out in the output of
"callgrind_annotate --auto=yes --inclusive=yes --threshold=100". The order,
position and times of the invocation does not matter. The number before the
"=>" should be consistent for each invocation instance. Please correct me if
my understanding is wrong.
>
> > Some times the bigger number of #A and #C corresponds to the Inclusive Ir
> > count of the function SR. Sometimes neither of them corresponds to the
> > Inclusive Ir count of the function SR and the sum of them is obvious
> beyond
> > that Inclusive Ir count.
>
> That sounds very wrong.
> Can you file a bug report?
>
Again, both #A and #C should be the exact Ir inclusive cost of this
invocation instance which could be found out in the output of
"callgrind_annotate --auto=yes --inclusive=yes --threshold=100".
>
> It would be good to provide a small test program with the wrong output you
> get.
> Thanks!
>
I will try it when I have a chance. Maybe I should try the --collect-jumps
option first.
>
> Josef
>
> > How should I understand the Ir count before the
> > "=>" symbol? Where can I find more detailed information about the
> annotated
> > source code? Any suggestion is appreciated!
> >
> >
> > Peace,
> > -David
> >
>
Thank you so much for your time and great help. I really appreciate it!
David
|
|
From: Josef W. <Jos...@gm...> - 2010-02-16 23:43:22
|
On Tuesday 16 February 2010, David wrote:
> without "--collect-jumps=yes" ("valgrind --tool=callgrind" only).
> Thank you for your reminder. I will check with the option
> --collect-jumps=yes after this discussion.
I was confused. "--collect-jumps=yes" is about jumps inside of a function,
but you just talk about calls. So, you can ignore this option.
> My assumptions are: (1) #B and #D should be the exact subroutine invoking
> counts for that line and (2) both #A and #C should be the exact Ir inclusive
> cost of this invocation instance
Yes.
> which could be found out in the output of
> "callgrind_annotate --auto=yes --inclusive=yes --threshold=100".
This should give the sum of the above inclusive Ir costs, as you talked about
the same called function (from same function), which maps to one line of the
summary list.
> The order,
> position and times of the invocation does not matter. The number before the
> "=>" should be consistent for each invocation instance.
What is the meaning of "consistent" here for you?
> > It would be good to provide a small test program with the wrong output you
> > get.
> > Thanks!
> >
>
> I will try it when I have a chance. Maybe I should try the --collect-jumps
> option first.
Just forget about this option :)
As I said: the fastest way to get the problem solved is to file a bug report
with an small test case which reproduces the problem. EMails easily get lost,
especially also for other users which have the same problem.
Josef
|
|
From: David <sho...@gm...> - 2010-02-17 01:03:15
|
Hello Josef,
On Tue, Feb 16, 2010 at 3:43 PM, Josef Weidendorfer <
Jos...@gm...> wrote:
> On Tuesday 16 February 2010, David wrote:
> > without "--collect-jumps=yes" ("valgrind --tool=callgrind" only).
> > Thank you for your reminder. I will check with the option
> > --collect-jumps=yes after this discussion.
>
> I was confused. "--collect-jumps=yes" is about jumps inside of a function,
> but you just talk about calls. So, you can ignore this option.
>
> > My assumptions are: (1) #B and #D should be the exact subroutine invoking
> > counts for that line and (2) both #A and #C should be the exact Ir
> inclusive
> > cost of this invocation instance
>
> Yes.
>
That is great.
> which could be found out in the output of
> "callgrind_annotate --auto=yes --inclusive=yes --threshold=100".
This should give the sum of the above inclusive Ir costs, as you talked
> about
> the same called function (from same function), which maps to one line of
> the
> summary list.
>
> > The order,
> > position and times of the invocation does not matter. The number before
> the
> > "=>" should be consistent for each invocation instance.
>
> What is the meaning of "consistent" here for you?
>
For example, if in a function F1(), the subroutine SR is called three times
at the beginning, the middle, and the ending, with #A, #C and #E before the
symbol "=>", respectively. These three numbers should be identical.
Furthermore, if another function F2() also call the same SR in the
execution, the number before the "=>" symbol of the invoking line in F2()
should also be that number. I call these results "consistent". At this
point, I understand the annotated source code in this way. If this is true,
I also have another quick question. If one subroutine SR is ever called by
two caller, F1() and F2(), how can I distribute Ir count across these two
functions since the Ir counts before the symbol "=>" are always the
inclusive Ir costs? Should I turn to using the calling count (ending with an
'x') to calculate the distribution percentage?
>
> > > It would be good to provide a small test program with the wrong output
> you
> > > get.
> > > Thanks!
> > >
> >
> > I will try it when I have a chance. Maybe I should try the
> --collect-jumps
> > option first.
>
> Just forget about this option :)
>
> As I said: the fastest way to get the problem solved is to file a bug
> report
> with an small test case which reproduces the problem. EMails easily get
> lost,
> especially also for other users which have the same problem.
>
> Josef
>
Currently I made one more run to reproduce this result in my system. If I
can reproduce it, I will contact the code developer to file a bug report.
Thank you so much for your great help.
David
|
|
From: Josef W. <Jos...@gm...> - 2010-02-19 10:51:44
|
On Wednesday 17 February 2010, David wrote: > > > The order, > > > position and times of the invocation does not matter. The number before > > the > > > "=>" should be consistent for each invocation instance. > > > > What is the meaning of "consistent" here for you? > > > > For example, if in a function F1(), the subroutine SR is called three times > at the beginning, the middle, and the ending, with #A, #C and #E before the > symbol "=>", respectively. These three numbers should be identical. Why? You have 3 different call sites, and every invocation of the same function can have different runtime, e.g. depending on parameters. Even if parameters are the same, the global program state will be different. E.g. some functions called inside are already resolved by the runtime linker, some not. System calls happening could need to be retried depending on the OS state, and so on... > Furthermore, if another function F2() also call the same SR in the > execution, the number before the "=>" symbol of the invoking line in F2() > should also be that number. No. For the same reasons as given above. If you are curious about where any differences are coming from, you can trigger a dump between calls to SR (e.g. use --dump-before=SR), and compare the multiple profiles in detail, e.g. on the machine code level (use --dump-instr=yes for this). > I call these results "consistent". At this > point, I understand the annotated source code in this way. If this is true, > I also have another quick question. If one subroutine SR is ever called by > two caller, F1() and F2(), how can I distribute Ir count across these two > functions since the Ir counts before the symbol "=>" are always the > inclusive Ir costs? Should I turn to using the calling count (ending with an > 'x') to calculate the distribution percentage? As shown above, this kind of "heuristic" can go very wrong. Can you tell me why you want to do this? In any case, the inclusive costs are exact, because they are measured directly. But for costs in SR, you only have the sum of multiple invocations. Perhaps "--separate-callers=2" does help here? With this, you would see 2 symbols for SR in the profile output: "SR called from F1" (given as SR'F1) and "SR called from F2" (SR'F2). Josef > Currently I made one more run to reproduce this result in my system. If I > can reproduce it, I will contact the code developer to file a bug report. > Thank you so much for your great help. > > David > |