is there better 32 clock() timing?
bokr at oz.net
Tue Jan 25 07:52:39 EST 2005
On Tue, 25 Jan 2005 11:42:35 +0000, Stephen Kellett <snail at objmedia.demon.co.uk> wrote:
>>>that time.clock() is inaccurate. The problem is that the "time.clock()"
>>>statement takes several hundred microseconds to execute.
>The statement is incorrect. clock() itself isn't slow, but it is
>accessing a resource, the accuracy of which is no better than 1ms.
I believe that is quite wrong as a general statement. It may be right
on some benighted system, but not on win32/NT python 2.4.
How do you account for getting deltas of 6-7 microseconds
in abs(clock()-clock()) ? If the "resource" only had ~1ms granularity,
the minimum would be zero, as it is if you call time.time() in a tight loop,
since it doesn't tick over often enough. time.clock does tick over fast
enough that you can't snag the same reading on two successive clock() calls
on a 300mhz P2.
>There are various timers available, documented and undocumented, all of
>which end up at 1ms or 1.1ms, give or take. For anything shorter you
>need QueryPerformanceCounter() (but that *is* a slow call), or use the
Have you timed it, to make that claim? What do you mean by "slow"?
>RDTSC instruction which is fast but gives a count of instruction cycles
>executed and is thus not totally accurate (multiple execution pipelines,
>plus multithreading considerations).
Accurate for what. A single clock AFAIK drives RDTSC
>You have to choose the system that works best for you. In many cases
>RDTSC works OK.
I wrote an extension to access it directly, and was agble to get down
to 23 cycles IIRC for a C call pair like above on a 300 mhz P2. 23/300 us I guess,
less than 100 ns between the clock reads of two calls.
The main problem with a CPU clock based reading is that it's very stable unless
there's variable clock rate due to power management.
Why am I doing this? ;-)
More information about the Python-list