[Developers] Proposed Cactus Timer API Completion

Gabrielle Allen gallen at cct.lsu.edu
Thu Aug 5 20:13:41 CDT 2004


In thinking about the API and functionality, remember that a lot of  
additional things can be implemented in a Timer thorn to keep the Flesh  
slim ... this has been the plan for a long, long time, but although it  
was started and planned out a couple of times never really got anywhere  
(and noone was asking for it apart from Eriks few feature requests).  
The idea was to have a thorn which would also provide the information  
in different customizable ways, including standard timers for different  
IO, reductions, communications etc, and including writing it to file,  
displaying it on the HTTPD interface, on the Cactus portal, and sending  
notifications to people when e.g. their MFlops dropped to an  
embarrassingly low value. As well as have the additional APIs to be  
able to manipulate the information easier.

We have an NSF proposal for performance and optimization submitted at  
the moment, which if funded will definitely include a lot of  
development of the timer functionality, if it isn't already done.

Gabrielle

On Aug 5, 2004, at 11:49 AM, Steve White wrote:

> Here is the latest version of the proposed completion of the Timer API.
> I made the names conform a little better with the existing ones.
>
> As it is, it has little impact on existing code.  It might be  
> worthwhile
> in the future to also provide a more complete and appropriate  
> developer's
> interface to the Timer library as well, and to re-write parts of the
> PerfReport thorn.
>
> This interface achieves support for any kind of clock.   (Once again
> though, a count of cache-misses is not a clock.)
>
> ======================================================================= 
> ==
> CCTK_NumTimerClocks
>
> Take a pointer to cTimerData and return the number of clocks recorded  
> in a
> timer measurement
>
> CCTK_GetClockValue, CCTK_GetClockValueI
>
> Given a clock referred to by name or index, respectively, and a  
> cTimerData
> pointer, return a cTimerVal pointer representing the value of the clock
> when the timer was stopped
>
> CCTK_TimerClockName
>
> Return the name of the clock given by the cTimerVal pointer argument.
>
> CCTK_TimerClockSeconds
>
> Return the floating-point value of the measurement in seconds from the
> cTimerVal pointer argument.
>
>
> ----------------------------------------------------------------------- 
> -
> 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 Tue, 3 Aug 2004, Gabrielle Allen wrote:
>
>>
>> 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
>>
>>
>> _______________________________________________
>> 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