[PerfSuite-users] =?gb2312?q?=BB=D8=B8=B4=A3=BA=20Re:=20=20Re:=20[Ptools-p?= =?gb2312?q?erfapi]=20Question=20Papi, =20how=20to=20use=20papi=20to=20prof?= =?gb2312?q?ile=20a=20real=20type=20of=20daemon=20process=3F?=

[liudawei <dbm...@ya...>]

Rick Kufrin :
   
  Thank your very much for your kindness. I have understand what you say.
  I will keep you posted of my work.
   
  Best regards
  Dawei Liu
   
   
  

Rick Kufrin <rk...@nc...> 写道：
  Dawei,

I'm glad to hear you are making a little progress. Regarding the reason 
for the zeroes appearing in your later tests: if you examine the output of 
psprocess you will notice that it indicates that multiplexing was enabled 
for the run with zeroes, but not for the run that returned actual event 
counts. I believe that this is the underlying reason that zeroes were 
reported.

On an Itanium 2 system such as you are using, there are only four actual 
registers available for the performance counters, which limits the number 
of events that can be counted at any given time. When you supply a 
configuration file that requires more events than the underlying hardware 
supports, PerfSuite switches into multiplexed operation (through PAPI). 
What that means is that the available registers are "timeshared" among the 
events: first one event is counted for a short period of time, then the 
next, then the third, and so on. At the end of the measurement, the 
events that were accumulated are scaled up accordingly and that is what is 
reported as the final result. This is an approximation, and for 
longer-running programs is usually quite good, but for shorter-running 
programs it can yield unexpected results. In the extreme, it is possible 
that the program being measured completed before one or more of the 
specified events had a chance to be "made active" even once.

I believe the current implementation of multiplexing in PAPI only allows 
for one event being active in any timeslice, even if the processor 
actually supports more than one.

So my guess is that what is occurring here is that your program is not 
running for long enough to accumulate any event counts when multiplexing 
is enabled. The run that did not report zeroes only ran for ~36,000 
cycles, which is much less than a second on your system.

My recommendation is to limit your runs to those that use configurations 
for which multiplexing is not required. This should at least give results 
that are greater than zero. Whether or not runs of these lengths provide 
information that is useful for analysis is another matter, but that's a 
judgement to be made by the end user.

There is currently no command-line utility in PerfSuite that allows one to 
query a given configuration file to learn if it would require multiplexing 
(this would be a useful addition, I think), so the easiest way is to 
experiment with commands like "ls" in combination with test configuration 
files and examine the output to see if multiplexing was used. Of course, 
it's good to know how many registers are available on your system in 
advance, as that lets you know the maximum, but you still have to do test 
runs because some PAPI events ("derived events") are actually composed of 
more than one underlying native event.

Rick

On Fri, 12 Jan 2007, liudawei wrote:

[ ... ]

> What is the problem happen ? Waiting your reply.
>
>
> Best Reagard
> Dawei Liu
> Renmin University of China
> 100872 Beijing,China
>
>
> ---------------------------------
> 抢注雅虎免费邮箱-3.5G容量，20M附件！

 		
---------------------------------
抢注雅虎免费邮箱-3.5G容量，20M附件！