On 2010-02-22, Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
> In article <87404349-5d3a-4396-aeff-60edc14a5...@f8g2000yqn.googlegroups.com>,
>>Gabriel Genellina reports that time.clock() uses Windows'
>>QueryPerformanceCounter() API, which has much higher resolution
>>than the task switcher's 15ms. QueryPerformanceCounter's
>>resolution is hardware-dependent; using the Win API, and a
>>little test program, I get this value on my machine: Frequency
>>is 3579545 ticks/sec Resolution is 0.279365114840015
>>microsecond/tick
>
> In Forth we add a small machine code routine that executes the
> RDTSC instruction. (I used that to play music on a couple of
> mechanical instruments in real time.) It just counts the (3
> Ghz) clock cycles in a 64 bit timer.
That's what clock.clock() does, except that it converts it into
a floating point value in seconds.
> Subtract two samples and you're done.
Nope. It would fail the same way that clock.clock() does on a
multi-core Windows machine.
> Is there a mechanism in Python to do something similar,
> embedded assembler or something?
You'd get the same results as using clock.clock(). Just
different format/units.
> (This is not a general solution, but at least it would work on
> Windows, that is i86 only.)
It fails on Windows for the same reason that clock.clock()
fails: the counters read by the RDTSC instruction are not
synchronized between the different cores.
--
Grant Edwards grante Yow! I'm a nuclear
at submarine under the
visi.com polar ice cap and I need
a Kleenex!
--
http://mail.python.org/mailman/listinfo/python-list
