is there better 32 clock() timing?

[Peter Hansen]

Stephen Kellett 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.
> 
> 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 
> 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).

(I've read the five or so following messages you and Bengt
have posted, but not in detail so I'm not sure where you're
going with all this, but... )

According to the docs for time.clock(), "On Windows, this function returns
wall-clock seconds elapsed since the first call to this function, as a floating
  point number, based on the Win32 function QueryPerformanceCounter(). The
resolution is typically better than one microsecond."

Depending on whether you really meant "accuracy" above, and
on other things, this is either irrelevant, or contradicts
your first statement...

-Peter