Rollover/wraparound time of time.clock() under win32?

[Russell Warren]

Does anyone know how long it takes for time.clock() to roll over under
win32?

I'm aware that it uses QueryPerformanceCounter under win32... when I've
used this in the past (other languages) it is a great high-res 64-bit
performance counter that doesn't roll-over for many (many) years, but
I'm worried about how many bits Python uses for it and when it will
roll over. I need it to take years to roll over. I'm also aware that
the actual rollover 'time' will be dependent on
QueryPerformanceFrequency, so I guess my real question is how Python
internally tracks the counter (eg: a 32 bit float would be no good),
but the first question is easier to ask. :)

time.time() is not an option for me since I need ms'ish precision and
under win32 it is at best using the 18.2Hz interrupt, and at worst it
is way worse.

I'd like to avoid having to make direct win32api calls if at all
possible.

In general - if anyone has any other approaches (preferrably platform
independent) for getting a < 1 ms resolution timer that doesn't roll
over for years, I'd like to hear it!

For now I have (for win32 and linux only):
#---
from sys import platform
if platform == 'win32':
from time import clock as TimeStamp
else:
from time import time as TimeStamp
print TimeStamp()
#---

This works for me as long as the clock rollover is ok and precision is
maintained.

Thanks,
Russ

[Peter Hansen]

Russell Warren wrote:

Does anyone know how long it takes for time.clock() to roll over under
win32?

I'm aware that it uses QueryPerformanceCounter under win32... when I've
used this in the past (other languages) it is a great high-res 64-bit
performance counter that doesn't roll-over for many (many) years, but
I'm worried about how many bits Python uses for it and when it will
roll over.

Check the source for yourself:

http://cvs.sourceforge.net/viewcvs.p....144&view=auto

(It takes the full 64-bit value and divides by the frequency, returning
a double. Whether or not that works for you only you can say.)

-Peter

[Russell Warren]

Thanks! That gets me exactly what I wanted. I don't think I would
have been able to locate that code myself.

Based on this code and some quick math it confirms that not only will
the rollover be a looong way out, but that there will not be any loss
in precision until ~ 30 years down the road. Checking my math:

(float(10**16 + 1) - float(10**16)) == 0
(float(10**15 + 1) - float(10**15)) == 1
ie: our double precision float can resolve unity differences out to
at least 10**15
Assuming 1 us/count we have 10**15 us / (3.15E13 us/year) = 31.7 yrs

Past this we won't roll over since the long keeps counting for a long
time, but some precision will be lost.

For those interested, the relevant win32 time code is below. Thanks
again!

time_clock(PyObject *self, PyObject *args)
{
static LARGE_INTEGER ctrStart;
static double divisor = 0.0;
LARGE_INTEGER now;
double diff;

if (!PyArg_ParseTuple(args, ":clock"))
return NULL;

if (divisor == 0.0) {
LARGE_INTEGER freq;
QueryPerformanceCounter(&ctrStart);
if (!QueryPerformanceFrequency(&freq) || freq.QuadPart == 0) {
/* Unlikely to happen - this works on all intel
machines at least! Revert to clock() */
return PyFloat_FromDouble(clock());
}
divisor = (double)freq.QuadPart;
}
QueryPerformanceCounter(&now);
diff = (double)(now.QuadPart - ctrStart.QuadPart);
return PyFloat_FromDouble(diff / divisor);
}

[Tim Peters]

[Russell Warren, playing w/ time.clock() on Windows]

...
Based on this code and some quick math it confirms that not only will
the rollover be a looong way out, but that there will not be any loss
in precision until ~ 30 years down the road. Checking my math:

(float(10**16 + 1) - float(10**16)) == 0
(float(10**15 + 1) - float(10**15)) == 1
ie: our double precision float can resolve unity differences out to
at least 10**15
Assuming 1 us/count we have 10**15 us / (3.15E13 us/year) = 31.7 yrs

It's about 9x larger than that (given your assumptions). A double has
exactly 53 significand bits on almost all boxes now:

2.**53+1 - 2.**53 0.0 2.**53 - (2.**53-1)

1.0

That is, all integers with absolute value <= 2**53 are exactly
representable as doubles.