[Developers] Proposed Cactus Timer API Completion

Gabrielle Allen gallen at cct.lsu.edu
Tue Aug 3 21:46:25 CDT 2004


Yes there is a PAPI thorn which can access hardware counters in an 
architecture independent way using the PAPI library ... and we have 
used it quite often for different optimizing and performance measuring 
things. We've wanted to get it more widely used, but previously have 
been hampered because the PAPI library required a linux kernel patch, 
I'm not sure if that is still true with the latest version.

I would really like an easier way to access the timing information, but 
would ideally like to see a way that didn't compromise having a general 
infrastructure for all clocks and timers. I don't see a problem with 
clocks which do not measure in seconds, you need to know exactly what 
clock you are using anyway to be able to interpret results in seconds.

I just looked at the bug reports for timers, I think I am missing the 
point about units and granularity? Why should units not be a string?

What is the actually use case that needs to be accommodated here? Maybe 
we could start from that?

Gabrielle

On Aug 3, 2004, at 4:27 PM, 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?  
> How hard can it be to generalize to measuring things with counters 
> whose physical interpretation may be something other than time?  Why 
> not just carry around a description string and a string for units?  In 
> the end I would rather have fewer general (but well thought out...) 
> APIs than lots of specific APIs to document and look up.
>
> -David
>
> ----- 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);
>>>>
>>>> ----------------------------------------------------------------
>> -------
>>>> -
>>>> Steve White : Programmer
>>>> Max-Planck-Institut für Gravitationsphysik
>>>> Albert-Einstein-Institut
>>>> Am Mühlenberg 1, D-14476 Golm, Germany
>>>> +49-331-567-7329
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>> Developers at cactuscode.org
>>>> http://www.cactuscode.org/mailman/listinfo/developers
>>>>
>>>>
>>> Gabrielle Allen
>>> Assistant Director for Computing Applications
>>> Center for Computation and Technology
>>> gallen at cct.lsu.edu
>>> +1 225 284 6605
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>> Developers at cactuscode.org
>>> http://www.cactuscode.org/mailman/listinfo/developers
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>> Developers at cactuscode.org
>> http://www.cactuscode.org/mailman/listinfo/developers
>>
>
>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>
>
Gabrielle Allen
Assistant Director for Computing Applications
Center for Computation and Technology
gallen at cct.lsu.edu
+1 225 284 6605





More information about the Developers mailing list