[Developers] Proposed Cactus Timer API Completion

Steve White swhite at aei.mpg.de
Thu Aug 12 02:52:14 CDT 2004


John,

I have implemented a Cactus timer with much finer granularity than the
default Cactus timers.  I expect to commit it soon.  Maybe this will help
with what you are doing.

Concerning changes to the interface:  I think it would be best if you
sketched out an interface that does what you want, and propose it formally
either here or as a "nice to have" on the Cactus bugs page.  I can assure
you that I'll look at it.


------------------------------------------------------------------------
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 Wed, 11 Aug 2004, John Shalf wrote:

> 
> On Aug 11, 2004, at 2:24 AM, Steve White wrote:
> > If the code is broken, well, I'm working on it right now, so I can
> > fix it.
> >
> > Could you send me an example?
> 
> Sure,
> I'll drag out some of the Earth Simulator results.
> The issue is not so much that it is broken per se.  The
> problem is that gettimeofday() is being used to time
> events that are far too short for it to time accurately.
> The result is that it reports completely bogus times,
> but offers no feedback mechanism to warn the user
> that this is the case.  I only catch it when I profile the code
> with the hardware performance counters.
> 
> A simple check of timer granularity can provide the
> necessary sanity for understanding the timing results.
> I can provide you with loop that does a fairly good job
> of estimating timer granularity across a number of systems.
> 
> Since Cactus uses an opaque handle for the timers, it
> seems like a good idea to make the "start/stop/add/subtract"
> time calls into virtual function table so that you can select
> more accurate system-specific implementations of
> timer APIs rather than having to resort to the lowest-common
> denominator get-time-of-day.
> 
> -john
> 
> > ----------------------------------------------------------------------- 
> > -
> > 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, 10 Aug 2004, John Shalf wrote:
> >
> >>
> >> Or perhaps I've misunderstood.  After re-reading your original
> >> posting, its not clear that you are going to rewrite any of the
> >> methods that Cactus uses to collect the timing data.  Are you
> >> focusing exclusively on adding 4 API calls to simplify the way
> >> that Cactus reports the timing results?
> >>
> >> Is *anyone* going to fix the broken methods currently used
> >> to collect the timing data?
> >>
> >> -john
> >>
> >> On Aug 10, 2004, at 4:14 PM, John Shalf wrote:
> >>> Steve,
> >>> do you want any non-get-time-of-day counter/timer examples?
> >>> For instance, I've got timers that use PAPI,  HPMCOUNT, and
> >>> Linux RTC counters to extract timing info at sub-microsecond
> >>> accuracy.
> >>>
> >>> I've been having significant problems with the gettimeofday()
> >>> based counter-timers giving incorrect results on the Cray and
> >>> NEC systems due to timer granularity issues.   I can provide
> >>> you with some specific examples where the Cactus timers
> >>> diverged from the hardware performance counters by 200%
> >>> or more in the final timer dump. So hiding more accurate
> >>> counter/timers beneath your API will be very useful
> >>> from my standpoint.
> >>>
> >>> In order to support these "hidden timers", the timer API
> >>> would benefit from simple opaque addition/subtraction
> >>> operators.  Internally, you can use a timer-dependent
> >>> accurate mechanism for performing the addition/subtraction
> >>> correctly.
> >>>
> >>> I think someone requested a subroutine call to request the
> >>> timer granularity.  I think collecting that data will be useful
> >>> to keep for the innards of your timing API for sanity checks.
> >>> For instance, if the elapsed time for any timer start/stop
> >>> event is < 8x the timer granularity, this should set some kind
> >>> of "flag" associated with that timer to indicate that its results
> >>> are not to be trusted.  So I'd advocate incorporating the
> >>> timer granularity into your API design even if that information
> >>> is only used internal to the timing API.
> >>>
> >>> -john
> >>>
> >>> On Aug 9, 2004, at 2:12 AM, Steve White wrote:
> >>>> Detailed enough for what?  Please provide more information.
> >>>>
> >>>> I wrote it in the style of the existing docs in the Users Guide.
> >>>>
> >>>> I am not re-writing the existing timer API, I'm completing the
> >>>> existing
> >>>> one to make it usable. This completion is not really comprehensible
> >>>> outside the existing Cactus timer context.
> >>>>
> >>>> As it now stands, the additional functions in cctk_Timers.h are
> >>>>
> >>>> unsigned int
> >>>> CCTK_NumTimerClocks( const cTimerData *info );
> >>>>
> >>>> const cTimerVal *
> >>>> CCTK_GetClockValueI( int valno, const cTimerData *info );
> >>>>
> >>>> const cTimerVal *
> >>>> CCTK_GetClockValue( const char * name, const cTimerData *info );
> >>>>
> >>>> double
> >>>> CCTK_TimerClockSeconds( const cTimerVal *clockVal );
> >>>>
> >>>> const char *
> >>>> CCTK_TimerClockName( const cTimerVal *clockVal );
> >>>>
> >>>> Given one understands that each Cactus timer starts multiple clocks,
> >>>> the
> >>>> only thing that isn't bloody is use of the 'GetClockValue'  
> >>>> functions.
> >>>>  But
> >>>> they follow the pattern of the existing functions.  The 'I'  
> >>>> indicates
> >>>> to
> >>>> get the clock value by index; otherwise you get it by clock name.
> >>>>
> >>>> Since they aren't named 'Create' or 'Make' or 'Allocate', and since
> >>>> there
> >>>> is no 'Free' function, you can surmise that there's no need to free
> >>>> anything.
> >>>>
> >>>> But this is all explained in the documentation.
> >>>>
> >>>>
> >>>> On Sat, 7 Aug 2004, Jonathan Thornburg wrote:
> >>>>>
> >>>>> Quoting from your E-mail of Thu, 5 Aug 2004 18:49:22 +0200 (CEST):
> >>>>>
> >>>>>> Here is the latest version of the proposed completion of the Timer
> >>>>>> API.
> >>>>>
> >>>>> I'm sorry, this is just not detailed enough.  After rereading it
> >>>>> many times I am still guessing at some details of what the  
> >>>>> functions
> >>>>> do.
> >>>>>
> >>>>> Could you perhaps post your draft of an actual API, i.e. with
> >>>>> actual C and/or Fortran function prototypes?  Some sample client
> >>>>> code showing typical usage would also be VERY useful in  
> >>>>> understanding
> >>>>> how the various pieces fit totether.
> >>>>>
> >>>> Above.
> >>>>
> >>>>> Are these proposed functions in *addition* to the existing ones in
> >>>>> section B10.1.2 "Timing Calls" of the Cactus Users' Guide, or are
> >>>>> they intended to *replace* the existing calls?
> >>>>>
> >>>> Complete, not replace.
> >>>>
> >>>>>> CCTK_NumTimerClocks
> >>>>>>
> >>>>>> Take a pointer to cTimerData and return the number of clocks
> >>>>>> recorded in a
> >>>>>> timer measurement
> >>>>>
> >>>>> I presume you mean "the number of different clocks recorded"
> >>>>> -- it took me considerable puzzling to determime that you meant  
> >>>>> that,
> >>>>> and not "the number of clock ticks (eg CPU cycles) recorded".
> >>>>>
> >>>> The notion of clocks is something special to the Cactus timer API.
> >>>> Not my idea, but there it is, and it does have some nice properties.
> >>>>
> >>>>> Looking at the Cactus Users' Guide, section B10.1 "Using Cactus
> >>>>> Timers",
> >>>>>  struct cTimerData  includes an  n_vals  field.  (In what way) does
> >>>>> CCTK_NumTimerClocks() differ from just looking at the value of that
> >>>>> field?
> >>>>>
> >>>> In the same way that calling an API function usually removes the  
> >>>> user
> >>>> from the underlying implementation details.
> >>>>
> >>>>> Are you proposing to keep the format of  struct cTimerData  public
> >>>>> (as in section B10.1.3), or make it opaque?  Ditto on  struct
> >>>>> cTimerVal ?
> >>>>>
> >>>> Opaque as a black cat when you're trying to read a newspaper.
> >>>>
> >>>>>
> >>>>>> 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
> >>>>>
> >>>>> Who owns the cTimerVal structure which the returned pointer points
> >>>>> to?
> >>>>> That is, if I call one of these functions N times in a row, does
> >>>>> someone
> >>>>> malloc N cTimerVal structures, so that I get N distinct pointers?   
> >>>>> Or
> >>>>> is there only a single static structure, which gets overwritten  
> >>>>> with
> >>>>> each call?
> >>>>>
> >>>> The timer owns it.  The user doesn't have to think about this.
> >>>>
> >>>>> I think it would be MUCH cleaner for the caller to pass in a  
> >>>>> pointer
> >>>>> to a cTimerVal struct, and the function to fill in that struct.
> >>>>> That way the ownership/lifetime issues are clear, and multiple
> >>>>> clients
> >>>>> can use these calls concurrently without interference.
> >>>>>
> >>>> Unnecessary, given there is no ownership issue.
> >>>>
> >>>> Not cleaner.  The user would then have to dispose of their copy.
> >>>>
> >>>>>
> >>>>>> CCTK_TimerClockName
> >>>>>>
> >>>>>> Return the name of the clock given by the cTimerVal pointer
> >>>>>> argument.
> >>>>>
> >>>>> (In what way) does this differ from the  heading  member of  struct
> >>>>> cTimerVal ?
> >>>>>
> >>>> See above about the general purpose of an API.
> >>>>
> >>>> -------------------------------------------------------------------- 
> >>>> --
> >>>> --
> >>>> 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
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> 
> 
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
> 
> 





More information about the Developers mailing list