time.clock() going backwards??

[Tim Peters]

[Giovanni Bajo[
>> I experimented something very strange, a few days ago. I was debugging an
>> application at a customer's site, and the problem turned out to be that
>> time.clock() was going "backwards", that is it was sometimes
>> (randomically) returning a floating point value which was "less than" the
>> value returned by the previous invokation. The computer was a pretty fast
>> one (P4 3Ghz I think, running Windows XP), and this happened only between
>> very close invokations of time.clock().

[Terry Reed]
> I seem to remember this being mentioned before on the list, perhaps by Tim
> Peters.  Perhaps he will chime in.

No real need ;-)  BIOS or HAL bug on a multiprocessor (or maybe even
hyperthreaded) box is by far the most likely cause (and the only cause
ever identified for sure by people who followed up).  Python's C code
slinging QueryPerformanceCounter is exceedingly simple, and isn't a
suspect because of that.  It's on the edge of vague possibility that
Microsoft's compiler generates non-monotonic code for converting
64-bit integer to double:  i.e., Python's C code obviously relies on
that if i and j are _int64 satisfying i >= j, then (double)i >=
(double)j.  If that type-conversion code /is/ monotonic (which is
almost certainly so), then the only ways the C code can fail are if
the HW counter overflows (in which case time.clock() would "jump" a
huge amount), or if the sequence of values returned by
QueryPerformanceCounter is itself non-monotonic at times (which is
consistent with known BIOS/HAL bugs).