a timer for benchmarking

[Dan Christensen]

Dan Christensen <jdc at uwo.ca> writes:

> I guess I'm wondering whether the Python developers have considered
> providing a more systematic and platform independent set of functions
> for accessing time.  For example, it would be nice to have access to
> the following choices:
>
> 1) cpu time used by the current process (e.g. time.clock under Unix)
>    "time.cpu"?
> 2) time as humans care about it (e.g. time.time under Unix/Windows)
>    "time.time"
> 3) time with respect to some arbitrary earlier point, with as
>    high resolution as possible (maybe time.clock under Windows?)
>    "time.elapsed" or "time.benchmark"?

...

> For example, a Pentium-class cpu can provide very high resolution time
> measurements through the time-stamp counter which counts the number of
> instructions since boot.

...

> Pretty good resolution!  And unaffected by changes to the human form
> of the system clock.  If Python can find out the clock speed, then

Tristan Seligmann <mithrandi at mithrandi.za.net> writes:

> It IS, however, affected by changes to the CPU clock speed. Such changes
> are quite frequent due to various power saving strategies on laptops,
> etc.

That's a good point.  So the time-stamp counter doesn't work for 3),
but works for 4):

4) cpu cycles since some arbitrary earlier point.

And, now that I think about it, this might be better than 3) for
benchmarking precisely because of possible cpu clock speed changes.
The number of cycles shouldn't be affected by cpu clock speed changes
as much as the elapsed time would.

Of course, for any serious benchmarking, one should disable variable
cpu clock speed in the BIOS, and then a high resolution measurement of
elapsed time would be nice to have.  The time-stamp counter was just
one possible method; are there alternatives available (in Linux on a
Pentium, say) that aren't affected by ntp and other changes to the
system clock?

Or maybe I should just do several runs and take the *second* best
time.time interval (instead of the best, as is often recommended)?

What about the issue of portability across OS's, and the fact that
time.clock isn't consistent.  Is this regarded as an issue?

Dan