Precise timings ?

Madhusudan Singh spammers-go-here at spam.invalid
Tue Aug 30 23:28:29 CEST 2005

Bengt Richter wrote:

> windows or unix? time.time and time.clock seem to reverse roles as
> best-resolution time sources depending on which platform.


time.time() seems to report (using %e to format the o/p) a fixed number of
the order ~1e9.

> If you have a pentium with a rdtsc instruction, you can write an extension
> module in c to get at it. In C on a 300mhz p2 I got down to 23ns minimum
> delta between calls, IIRC. But even then I was subject to the small

I do not need ns resolution. A few microseconds would be fine.

> probability of an interrupt during my timing loop, and there are many
> normally going on, so the longer the interval you are timing the greater
> the probability that an interrupt will occur within it (assuming random
> independence, which is also not necessarily true). This is why timing
> frameworks generally either average brute force or discard outlier timings
> and average, or return best-of. All these have different error properties,
> and depend on lots of stuff.
> I'm wondering whats your application is. Maybe you need a real-time OS?

No, no. All I am looking for is for the system to report its time with
better resolution. I know it is possible on my hardware, because I can get
at very precise timings using Fortran 95 intrinsics in my other code.
However, with Python's time module, I do not seem to be able to access it.

More information about the Python-list mailing list