Goal: Provide platform dependent timing routines that share
a common Application Programming Interface (API).
Ptools will provide a central access point for platform-specific
implementations of the routines.
- It would be more appropriate to refer to these routines as
"universal" rather than "portable" timing routines.
- Provide the least intrusive timing calls for each platform
- - that are callable from FORTRAN or C
- - the library will be made available as source over the Internet
- Meant to be used as interval timers
- - for measuring elapsed time between two points of execution
- - will not be a time-of-day indicator
- Typical uses
- - measure improvement against some baseline version on same platform
- - compare performance of alternatives (algorithms, data
distribution, message size, etc.)
What We Are Not Trying to Do
- We are not trying to provide Fortran or C code that can be ported to
- - this is already provided (minimally) by the UNIX time-of-day
- Define or standardize how user CPU or system CPU time is measured
- - the definition of these quantities varies from system to system
- - it is difficult to categorize what belongs in each
- Standardize the accuracy/granularity at which times are reported
- - this varies across platforms
- Provide measure of time for comparison across platforms
- Provide "Global timestamp" facility for recording when events occured
Basic Terms Used for PTR
The following terms are used in establishing the semantics of
the portable timing routines. The exact units measured and the size of the
values measured may differ across platforms.
- Timer value
- The value returned by a call to a timer routine. This represents the
current value of the timer (e.g. an appropriate register). There are
three types of timer values:
- a) User timer value.
This is the value of the timer that measures the CPU time billed to
the user (platform-dependent).
- b) System timer value.
The value of the timer tracking the CPU time used for system activities
- c) Wallclock timer value.
The value of the wallclock, or time-of-day, timer (may be measured in
a platform-dependent way such as relative to some previous moment).
- Timer values are only meaningful when used to calculate elapsed time, or
the interval between the points at which timer values are obtained.
- The smallest unit of user, system, or wallclock time measurable on a
system. It is a measure of the underlying clock rate and will be system
- Tick frequency
- A measure of the tick granularity (e.g. number of ticks per second) for
user, system, or wallclock time on a given platform. There are two types of
- a) Nominal tick frequency.
The reference value supplied by the vendor.
- b) Calibrated tick frequency.
The value obtained from a calibration program. This is the value for
a particular instance of a specific platform, and takes into account
variation in hardware and software versions on a given platform.
- The minimal time unit that can be measured with confidence. It will be at
least as coarse as the tick size, and probably coarser since many timers
operate as step, rather than continuous functions. This value will be
nominal (i.e., supplied by the vendor) indicating the number of bits that
should be considered valid when calculating elapsed time.
- Rollover frequency
- The number of ticks that can be accommodated before a timer rolls over or
is reset. This value will be nominal (i.e., supplied by the vendor).
- Overhead (or Intrusion)
- The cost (intrusiveness) of using one of the timer routines to capture a
timer value. This cost will be calibrated (i.e., obtained from a calibration
Use of Portable Timing Routines
- "Timer" calls grab the timer value (e.g., register values)
- User saves these timer values
- User calls the conversion functions on any two saved timer values (of the
same type, e.g. user timer values)
- Conversion function returns interval expressed in meaningful units
Other Options Considered
- Timers return meaningful units at each call ( the appropriate register is read and the value is converted to meaningful time units).
- - Pros: this would eliminates the problem with overlapping intervals
- - Cons: Too intrusive - user can't control where overhead was incurred
- Software timers: user instantiates/starts/stops/reads the timer (stopwatch metaphor)
- - Pros: conversion not needed for start/stop
- - Cons: need multiple timers if intervals overlap
- OUR CHOICE: Use opaque timer values.
- - Pros: user controls overhead by making explicit conversion calls
- - Cons: timer values of themselves are meaningless
Portable Timing Routines home page
Parallel Tools at OSU home page
Parallel Tools Consortium home page
For further information, contact