Tim Roberts <[EMAIL PROTECTED]> wrote: > Nick Craig-Wood <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list