Gary,
On Wed, May 14, 2008 at 2:07 AM, <[EMAIL PROTECTED]> wrote:
> Columns correspond to the following events [event:period (events/sample)]
> CPU_OP_CYCLES_ALL:32767 - CPU Operating Cycles -- All CPU cycles counted
> (35 samples)
> CPU_OP_CYCLES_ALL:32767 - CPU Operating Cycles -- All CPU cycles counted
> (0 samples)
> CPU_OP_CYCLES_ALL:32767 - CPU Operating Cycles -- All CPU cycles counted
> (38 samples)
> CPU_OP_CYCLES_ALL (min):32767 - CPU Operating Cycles -- All CPU cycles
> counted (The minimum for events of this type.) (0 samples) [not shown]
> CPU_OP_CYCLES_ALL (max):32767 - CPU Operating Cycles -- All CPU cycles
> counted (The maximum for events of this type.) (63 samples) [not shown]
> CPU_OP_CYCLES_ALL (sum):32767 - CPU Operating Cycles -- All CPU cycles
> counted (Summed over all events of this type.) (73 samples) [not shown]
>
> The multiplication of samples times period (73 * 32767) give me:
>
> 2,391,991 Cpu cycles used
>
This is not a valid way of computing the number of cycles. It assumes
you did monitor the entire
execution of your test program. However, this is not necessarily true
for non self-monitoring programs.
There are blind spots when the sampling buffer fills up. This is due
to the fact that the default sampling
buffer does not use a double-buffering technique (a double buffer
format is planned). Thus when it fills up,
monitoring stops but execution continues by default unless you've used
--overflow-block in pfmon or the
equivalent context flag is set by hpcrun/PAPI.
Also you may want to use --follow-all for pfmon as this option also
follows across exec which is what
happens with system().
> But the results in the file ./pfmon show:
>
> 26,045,577,230 CPU_OP_CYCLES_ALL
>
> The test actually runs about 20 seconds on my system which makes the number
> reported by pfmon appear to be accurate.
>
>
> If I comment out the line (to rerun the test without the fork):
> system("ls -al");
>
> Then recompile and rerun the test:
>
> The only hpcrun data file created is:
>
> -rw-r--r-- 1 hpctk users 1392 May 13 16:09
> ForkTest.CPU_OP_CYCLES_ALL.molson.19814.0x4d66
>
> The results in the file ./hpcprof show :
>
> Columns correspond to the following events [event:period (events/sample)]
> CPU_OP_CYCLES_ALL:32767 - CPU Operating Cycles -- All CPU cycles counted
> (795988 samples)
>
> Which represents:
>
> 26,082,138,796 Cpu cycles used
>
> The pfmon results for this test run reports:
>
> 26,045,163,278 CPU_OP_CYCLES_ALL
>
> It is clear from these test results that hpcrun does not work correctly for
> this type of executable and the problem is now easily reproducable.
>
> I do not know if the workaround you have considered is the best way to fix
> this or if the PAPI fix is a better way to go. But if you guys can point
> me
> in the right direction and give me an idea what needs to be changed, I am
> willing to try and implement the fix. I just want to come up with a
> correction
> that someone with the authority to commit changes to the CVS/SVN would be
> willing to put into a future release.
>
> Thanks for your time,
>
> Gary
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> perfmon2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
perfmon2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
