Re: [PerfSuite-users] libpshwpc; working around implicit variables?

[Rick K. <rk...@nc...>]

Tirath - looks like two issues here.  For this one:

> To begin with, is it normal/explainable that running psrun in  
> counting mode counts far more samples of a given event than when  
> running in profile mode? For example, I've been getting the following  
> with my program:
> 
> PAPI_L2_LDM:
> Counting: 5452797 samples
> Profil: 305 samples (total)
> 
> The case is similar for PAPI_RES_STL and PAPI_TOT_CYC, and I haven't  
> tested any others yet.

If I understand your question properly, it is: why aren't the number of 
samples when profiling identical to the number of observed events when 
counting?  Assuming I have that right, the answer is that it's because the 
nature of the measurements are different.

For counting runs, the number of events reported should be the total number
of events actually observed (except when multiplexing is involved, in which
case it is an estimate).  It's an aggregate count of total event 
occurrences.

For profiling runs, a sample is recorded for only every Nth occurence of 
an event (where N is user-selectable in PerfSuite, either through the 
psrun command-line option "-t" or through the environment variable 
PS_HWPC_THRESHOLD).  So if the total of events that occurred during the 
run of an application is M, then the total number of samples S recorded 
should be M/N, or equivalently M = N*S.  Substituting your numbers above:

M = 5452797
S = 305

and so N ~= 17878.  The default threshold for PerfSuite 0.6.1 profiling is 
10000, which is in the ballpark.  In 0.6.2 it was raised to 100000, which 
is less likely to cause excessive overhead due to the interrupt handler 
that's invoked every time the threshold is reached.  You might try raising 
the threshold value and running your experiments again to see if you can 
bring the calculations more closely in line (although they will probably 
never match exactly)  

> I figured I'd try invoking libpshwpc directly in the program instead  
> of relying on psrun... but that may not be so simple as the code I  
> have to work with is some pretty old Fortran. I'm pretty new to  
> Fortran, so I don't know how correct my analysis is, but I think the  
> problem is the code I have to work with relies heavily on implicit  
> variables. Here's what I get when trying to compile:
> 
> g77 -c -O2 -I/usr/local/include -malign-double -fautomatic -Wno- 
> globals -fno-globals gamess.f
> source/gamess.srcpp: In program `gamess':
> source/gamess.srcpp:320:
>           IMPLICIT DOUBLE PRECISION(A-H,O-Z)
>           1
> fperfsuite.h:45: (continued):
>           integer PS_PID, PS_PPID, PS_PGRP, PS_SESSION, PS_TTY,
>           2
> Statement at (1) invalid in context established by statement at (2)
> ... (it goes on like that)...
> 
> Does anyone know of a workaround for situations like this?
> 

I tried to reproduce this error with g77 version 3.4.4 and had no problem. 
Do you know which version of g77 you're using? (g77 --version)

Rick