[Developers] Proposed Cactus Timer API Completion

Steve White swhite at aei.mpg.de
Wed Aug 4 03:22:16 CDT 2004


David,

On Tue, 3 Aug 2004, David Rideout (drideout) wrote:
>
> Isn't there a PAPI thorn which measures all sorts of fun things such
> as cache misses and integer operations, using the Cactus timer API? 
>
Do you mean AlphaThorns/PerfReport?  It's the only thorn I've found that
uses the Cactus Timers interface beyond using the Timer's built-in print
function.  And yes, it returns Flop rates and L2 cache misses.
 
> How hard can it be to generalize to measuring things with counters
> whose physical interpretation may be something other than time?  
>
And where will it end?
Perhaps we could report spatial variables with the Timer API as well.

Permit me to repeat: it is reasonable to expect a timer (or clock) to
report time, and NOT something other than time.

> Why not just carry around a description string and a string for units?
> 
This is what the existing timers do.  There are bug reports open on the
subject.

For some purposes (printing) this is adequate.  For dealing with different
units programmatically, it's a big problem.  For example, if one wants to
compare two timer results, one of which returns 'secs' and the other of
which returns "clock cycles", what does one do?  Well, one spends some
time with manuals and does some programming.  If the units can be reported
arbitrarily, what if you don't know beforehand the interpretation of these
arbitrary units?

It's all unnecessary.  The writer of the clock has the needed low-level
information.  By providing the result to the user as a double representing
seconds they have done the the calculation that the user would otherwise
be forced to do.

And as I've pointed out before, if it can't be represented as a double
it ain't 'time'.

> In the end I would rather have fewer general (but well thought out...)
> APIs than lots of specific APIs to document and look up.
> 
The logical extreme of your suggestion isn't an API at all.  For complete
generality, one can use a programming language in a system that permits
direct access to hardware.  No need to deal with API's at all.

The issue is whether or not a generalization is appropriate, rather than
how many API's are presented.  An API that is general as are the existing
timers isn't simple.  It's messy and hard to use; people start looking for
other solutions.


 
> 
> ----- Original Message -----
> From: Steve White <swhite at aei.mpg.de>
> Date: Tuesday, August 3, 2004 1:19 pm
> Subject: Re: [Developers] Proposed Cactus Timer API Completion
> 
> > Gab,
> > 
> > I don't agree.
> > 
> > A timer should report time.  This concept alone is fuzzy enough 
> > (CPU, wall
> > time, time spent doing various tasks, etc) without fouling it 
> > further with
> > the capacity to represent any bloody thing you please.
> > 
> > A number of cache misses isn't time.  I would suggest to devise a 
> > separateAPI for such things as counting cache misses, and to call 
> > it something
> > other than 'Timer'.  (How about "Counter".)
> > 
> > This is a practical point -- a messy interface without a clear 
> > focus will
> > end up being practically useless.
> > 
> > --------------------------------------------------------------------
> > ----
> > Steve White : Programmer
> > Max-Planck-Institut für Gravitationsphysik      Albert-Einstein-
> > InstitutAm Mühlenberg 1, D-14476 Golm, Germany                  +49-
> > 331-567-7329
> > 
> > On Tue, 3 Aug 2004, Gabrielle Allen wrote:
> > 
> > > 
> > > Note that "clocks" are not just measuring in seconds, but need to 
> > 
> > > report on all kinds of hardware and other timers: MFlops, Flops, 
> > cache  
> > > misses, ...
> > > 
> > > On Aug 3, 2004, at 7:54 AM, Steve White wrote:
> > > 
> > > > The existing API for Cactus Timers provides accessors for 
> > Timers, but
> > > > peters out when it comes to getting information for a 
> > particular clock
> > > > within a timer value.  The interface consists of a structure 
> > definition> > (see Chapter B10.1 of the Users' Guide).
> > > >
> > > > There is something a bit wrong-headed about the existing clock  
> > > > structure.
> > > > It records information as a type that is convenient for the low-
> > level> > timer (as an int, long, or double), although the user 
> > invariably wants  
> > > > the
> > > > time period in seconds.  There are outstanding bug reports to 
> > this  
> > > > effect.
> > > >
> > > > Accordingly, I propose to add the following functions to the 
> > Timer API:
> > > >
> > > > 
> > ====================================================================> > unsigned int
> > > > CCTK_NumTimerClocks( const cTimerData *info )
> > > > 	// Gets the number of clocks recorded in a timer measurement
> > > >
> > > > const cTimerVal *
> > > > CCTK_GetClockValNumber( int clockno, const cTimerData *info );
> > > > 	// Gets the clock value with the given number from the
> > > > 	// timer measurement
> > > >
> > > > const cTimerVal *
> > > > CCTK_GetClockValNamed( const char * name, const cTimerData 
> > *info );
> > > > 	// Gets the clock value for the clock with the given name
> > > > 	// from the timer measurement
> > > >
> > > > const char *
> > > > CCTK_TimerClockName( const cTimerVal *clockVal );
> > > >         // Gets the name of the clock corresponding to the 
> > clock value
> > > >
> > > > double
> > > > CCTK_TimerClockSeconds( const cTimerVal *clockVal );
> > > > 	// Gets the value of the measurement in seconds from the clock
> > > > 	// value
> > > > 
> > ====================================================================> > The intent is to protect the user entirely from the internals of the
> > > > cTimerVal and cTimerData structures.
> > > >
> > > > The code snippet in B10.1.4 "Accessing the timer results" becomes
> > > >
> > > >    cTimerData *info = CCTK_TimerCreateData();
> > > >    int nclocks = CCTK_NumTimerClocks( info );
> > > >
> > > >    for (i = 0; i < numclocks; i++)
> > > >    {
> > > >      const cTimerVal   *clock = CCTK_GetClockValNumber( i, info );
> > > >      printf ("\t%s: %.3f %s\n", CCTK_TimerClockName( clock ),
> > > >                                 CCTK_TimerClockSeconds( clock 
> > ),  
> > > > "secs" );
> > > >    }
> > > >    CCTK_TimerDestroyData (info);
> > > >
> > > > ----------------------------------------------------------------
> > ------- 
> > > > -
> > > >
> > > >
> > > Gabrielle Allen
> > > Assistant Director for Computing Applications
> > > Center for Computation and Technology
> > > gallen at cct.lsu.edu
> > > +1 225 284 6605
> > > 
> > > 
> 
------------------------------------------------------------------------
Steve White : Programmer
Max-Planck-Institut für Gravitationsphysik      Albert-Einstein-Institut
Am Mühlenberg 1, D-14476 Golm, Germany                  +49-331-567-7329






More information about the Developers mailing list