[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oprofile-list
Subject:    Re: strange opannotate output
From:       Maynard Johnson <maynardj () us ! ibm ! com>
Date:       2008-08-11 13:55:44
Message-ID: 48A044E0.2030802 () us ! ibm ! com
[Download RAW message or body]

Yoshitake, Aaron wrote:
> Hello, I'd like to ask a question about oprofile results I'm getting for
> a very simple program, looper.c, which I have attached.
>
> As you can see, the looper program runs an infinite loop, and should
> spend 2/3 of the time inside the if-else clause on line 9, and 1/3 of
> this time on line 12.
>   
I suspect this is at least partially due to inaccuracy in the h/w and
oprofile kernel code in pinpointing the exact location of a sample (see
the "Profiling interrupt latency" section of the "Interpreting profile
results" chapter in the OProfile user manual).  Profiling looper on a
POWER5 system using PM_CYC event, I saw pretty much the same result you
did.  But when I profiled with PM_MRK_INST_FIN_GRP115 (a "marked" event
that yields accurate instruction sampling), my results showed a
proportional difference between the "if" and "else" clauses that was
much closer to theoretical expectation -- although, still not exact. 
Since OProfile is a statistical profiler, I would expect the results to
get closer to exact the longer I run this test.

-Maynard
> I compiled this program and ran oprofile using the following commands:
>
>  
>
> gcc -g -o looper looper.c
>
> opcontrol --start
>
> ./looper
>
> [wait 5-10 minutes]
>
> opcontrol --stop
>
> opannotate -s -a looper
>
>  
>
> Attached is the output from running opannotate (output2.txt). Also
> attached is the output from doing the same process, but after changing
> line 8 of looper.c to 
>
> if (x % 3 == 0) {
>
> (output.txt)
>
>  
>
> As you can see from the output, in both trials, the vast majority of the
> samples made during the if-else clause are attributed to line 12.
> Although in output.txt line 12 should only see twice as many samples as
> line 9, and in output.txt line 9 should see twice as many as line 12, we
> get these results.
>
> What could be causing this? Poor compiler optimizations or disparities
> in times for instructions can be ruled out; as the output also shows,
> the only difference between the assembly generated by the two files is a
> "jne" instead of a "je" where the if-logic ends. The only difference
> between line 9 and line 12, in assembly, is a jump, so what is causing
> the huge difference in processor usage?
>
>  
>
> Thanks for any help you can give. 
>
>  
>
> Aaron Yoshitake
>
> Office Phone: (760) 931-4468
>
> Cell Phone: (510) 225-8187
>
>  
>
>
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> oprofile-list mailing list
> oprofile-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
>   



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
oprofile-list mailing list
oprofile-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
[prev in list] [next in list] [prev in thread] [next in thread]