On Tue, 25 Jan 2005 11:42:35 +0000, Stephen Kellett <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
