[Developers] Proposed Cactus Timer API (Posix timers)

John Shalf jshalf at lbl.gov
Fri Aug 13 14:41:28 CDT 2004

I've attached examples of how PAPI and HPM timers are used for 
benchmarking purposes.  I was going to extract them from the code, but 
it might be better to see them used in context.  There are only a 
handful of calls to PAPI and HPM timing routines in all, so it should 
be pretty easy to see what is going on...

Both of these timers tap into the hardware timers on the CPUs to get 
timings that are accurate to within a few CPU cycles.  PAPI offers an 
abstraction layer that works across multiple CPU architectures, but 
requires a kernel mod to get it installed (hence its availability is 
system-administrator dependent).  The HPM toolkit is available on most 
AIX/Power3/4/5 systems (but only on IBM AIX... nothing else).

This should offer two more timing methods to add to a growing 
collection.  (hence the desire for a way to select among several timing 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hpmcount.c
Url: http://www.cactuscode.org/pipermail/developers/attachments/20040813/206e297f/attachment-0002.c 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: papi.c
Url: http://www.cactuscode.org/pipermail/developers/attachments/20040813/206e297f/attachment-0003.c 
-------------- next part --------------

On Aug 13, 2004, at 10:05 AM, Steve White wrote:
> John,
> Your proposal makes a lot of sense as a means of determining a working
> value for precision, in the sense of the repeatability of measurement.
> I'll think about what it would mean to implement it in Cactus.  I think
> I'll play with your program a bit this weekend...
> As to the question of accuracy, in the sense of agreement with "real"  
> time
> (in the context of the clock in question):  By definition it's  
> something
> that can't be determined from within the system.
> I was working from the notion of resolution, as a lower bound for the
> minimum turn-over time for the clock.  This is of some use by itself.
> The loops I wrote are just a crude means of looking at that time.  I  
> was
> hoping that more API's would provide such a thing, but found that some  
> of
> the resolutions provided by standard timers don't even make sense (the
> POSIX timers).
> I did write that thorn based on the MPI timer (it's in AlphaThorns  
> now),
> which I think does something internally like your "hidden timers"
> suggestion:  It finds the best high-resolution timer for the system.   
> It
> also provides a resolution (for what it's worth). There is a bug with  
> it
> that I hope to fix soon.
> I will also think about a thorn for POSIX timers.  It's easy enough and
> shouldn't suffer from the same problems as the MPI timer, although
> portability is a problem.
> ----------------------------------------------------------------------- 
> -
> Steve White : Programmer
> Max-Planck-Institut f?r Gravitationsphysik       
> Albert-Einstein-Institut
> Am M?hlenberg 1, D-14476 Golm, Germany                   
> +49-331-567-7329
> On Thu, 12 Aug 2004, John Shalf wrote:
>> Just looking through the code, I see that you are looking at the first
>> timer "turn over" of the clock timer to estimate the timer resolution.
>> It is necessary to find the average & standard deviation of the
>> granularity of clock turn-overs.  In order to determine the accuracy  
>> of
>> the timer, you have to take the average of many timer "turn over"
>> events.  The precision is related to the standard deviation of the
>> turn-over events (assuming the method of sampling is faster than the
>> timer.. I think this is generally true for a simple timing loop).  I
>> think this is probably why the results are inconsistent with the
>> resolution function.
>> I've attached a program that I've been using to compare gettimeofday()
>> implementations on different platforms.  I'm sure it can be adapted  
>> for
>> the posix timers.
>> So on a BSD system, I get the following timing report
>> 	Mintime=1 usec Maxtime=20979 usec Average= 1.47511 usec
>> I get pretty accurate timing on the BSD system for the default cactus
>> timers (with a few exceptions).
>> On the Cray X1 I get the following timing report
>> 	phoenix% ./a.out
>> 	Mintime=56 usec Maxtime=15200 usec Average= 101.719 usec
>> Accuracy and precision will tell you different things about the  
>> meaning
>> of the timing results. On the X1, the timer will not be accurate for
>> measuring events that are less than the average timing granularity.  I
>> didn't compute the std deviation, but if you do so, it will provide  
>> you
>> with enough detail to estimate the precision of the timer (and
>> consequently the precision of the timing results +/- some percentage).
>> The range of timings (mintime vs. maxtime) indicate that standard
>> deviations are going to be pretty large.  When I plotted the histogram
>> of the timings, it looks a lot like a poisson distribution (makes  
>> sense
>> I guess).
>> -john
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers

More information about the Developers mailing list