time.clock() or Windows bug?

Nick Craig-Wood nick at craig-wood.com
Mon Jun 9 11:30:46 CEST 2008

Tim Roberts <timr at probo.com> wrote:
>  Nick Craig-Wood <nick at craig-wood.com> wrote:
> >
> >time.clock() uses QueryPerformanceCounter under windows.  There are
> >some known problems with that (eg with Dual core AMD processors).
> >
> >See http://msdn.microsoft.com/en-us/library/ms644904.aspx
> >
> >And in particular
> >
> >    On a multiprocessor computer, it should not matter which processor
> >    is called. However, you can get different results on different
> >    processors due to bugs in the basic input/output system (BIOS) or
> >    the hardware abstraction layer (HAL). To specify processor
> >    affinity for a thread, use the SetThreadAffinityMask function.
>  That's an extremely arrogant statement on their part, because the fault
>  here is entirely within Windows.
>  Through Windows 2000, the operating system actually synchronized the cycle
>  counters on the additional processors as they came out of reset at boot
>  time.  (The cycle counter is, after all, a writable register.)  As a
>  result, the cycle counters were rarely off by more than about 20 cycles.
>  Beginning with XP, they stopped doing that.  As a result, the cycle
>  counters on multiprocessor machines can vary by millions or even tens of
>  millions of cycles.

Hmmm, 10,000,000 cycles (40 ms @2.5GHz) is nowhere near the ~90,000
second jump in time.clock() output reported by the OP.  I wonder if
there could be a different cause?

Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick

More information about the Python-list mailing list