is there better 32 clock() timing?

[Stephen Kellett]

In message <41f63d79.1778950866 at news.oz.net>, Bengt Richter 
<bokr at oz.net> writes
>I believe that is quite wrong as a general statement.

Actually my initial statement should have been written
"accessing a resource, the accuracy of which is no better than 10ms.". I 
was thinking of the 1ms multimedia timer but wrote about clock() 
instead.

10ms, coincidentally is the approx minimum scheduling granularity for 
threads unless you are in a multimedia thread (or real time thread - not 
sure about real time threads in NT).

>If the "resource" only had ~1ms granularity,
>the minimum would be zero, as it is if you call time.time() in a tight loop,

Correct. Write your app in C and call clock(). Thats what you get. You 
can call clock 20000 times and still get a delta of zero. The next delta 
(on my system) is 10ms at about 22000 calls.

>>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

Whoops here we go, same typo - should have been 10ms or 11ms. There is a 
1ms timer in the multimedia timing group.

>>need QueryPerformanceCounter() (but that *is* a slow call), or use the
>Have you timed it, to make that claim?

Yes.

>What do you mean by "slow"?

Slower than any other Win32, CRT or Undocumented NT function you can use 
to get timer information. Yes, I have timed them all, a few years ago.

QueryPerformanceCounter is 47 times slower to call than clock() on my 
1Ghz Athlon.

QueryPerformanceCounter may have finer granularity, but called in a 
tight loop it'll crush your program.

>>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.

See below - you haven't taken things into account, despite my comment in 
brackets above which gives a big hint.

>A single clock AFAIK drives RDTSC

Correct.

>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.

Try running multiple apps at the same time you are doing your 
measurement, each of which has a variable loading. Each of these apps is 
contributing to the count returned by RDTSC. That is what I was 
referring to.

Stephen
-- 
Stephen Kellett
Object Media Limited    http://www.objmedia.demon.co.uk
RSI Information:        http://www.objmedia.demon.co.uk/rsi.html