time.clock() or Windows bug?
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