is there better 32 clock() timing?

[Bengt Richter]

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? ;-)

Regards,
Bengt Richter