[Developers] Proposed Cactus Timer API Completion

Steve White swhite at aei.mpg.de
Wed Aug 11 04:24:00 CDT 2004


If the code is broken, well, I'm working on it right now, so I can
fix it.

Could you send me an example?

------------------------------------------------------------------------
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
> 
> 





More information about the Developers mailing list