|Efficient Execution Time Profiling ? firstname.lastname@example.org (1992-04-29)|
|Re: Efficient Execution Time Profiling ? email@example.com (1992-04-30)|
|Re: Efficient Execution Time Profiling ? firstname.lastname@example.org (1992-05-08)|
|Re: Efficient Execution Time Profiling ? email@example.com (1992-05-09)|
|Re: Efficient Execution Time Profiling ? firstname.lastname@example.org (1992-05-11)|
|From:||email@example.com (David Keppel)|
|Organization:||Computer Science & Engineering, U. of Washington, Seattle|
|Date:||Thu, 30 Apr 1992 18:14:49 GMT|
firstname.lastname@example.org (Thomas Fahringer) writes:
John Levine writes:
>[System calls; what do other systems do?]
Some specific systems have accurate clocks that can be accessed at low
and/or predictable delay. ``Accurate'' in this case can vary from (number
of clock cycles since boot) mod 2^32 to something loose but still tighter
than you can get from the system calls. These clocks are all
machine-dependent but can often be encapsulated with a zero or fixed cost.
The Sequent Balance and Symmetry have timers. The Symmetry is a
microsecond timer that at any given time has the same value at all CPUs.
There is a variable delay to access the timer but it is statistically
small. About 5 simple (80386) instructions are executed per clock tick.
The (older) Balance timer requires shared-bus access and thus has longer
latency and higher variability.
I believe the HP Precision falls in the category of ``number of clock
cycles since boot.'' Last year at ASPLOS somebody said that the readable
clock precision could be adjusted and could only be increased by the
kernel. This was so that security-conscious systems could avoid cracks
based on fine timing.
;-D on ( Antifile, Prodefile ) Pardo
Return to the
Search the comp.compilers archives again.