In message <[EMAIL PROTECTED]>, Bengt Richter <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to