[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). -- http://mail.python.org/mailman/listinfo/python-list