Precise timings ?
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