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

Discussion in 'Python' started by Russell Warren, Sep 28, 2005.

  1. 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
     
    Russell Warren, Sep 28, 2005
    #1
    1. Advertising

  2. Russell Warren

    Peter Hansen Guest

    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..../src/Modules/timemodule.c?rev=2.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
     
    Peter Hansen, Sep 29, 2005
    #2
    1. Advertising

  3. 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);
    }
     
    Russell Warren, Sep 29, 2005
    #3
  4. Russell Warren

    Tim Peters Guest

    [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.
     
    Tim Peters, Sep 29, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Valentin Tihomirov

    Are clock and divided clock synchronous?

    Valentin Tihomirov, Oct 23, 2003, in forum: VHDL
    Replies:
    11
    Views:
    3,299
    louis lin
    Oct 28, 2003
  2. Dave Rahardja
    Replies:
    5
    Views:
    1,113
    John Harrison
    Jul 18, 2003
  3. David Mathog
    Replies:
    24
    Views:
    850
    Eric Sosman
    Jun 3, 2004
  4. Dan
    Replies:
    8
    Views:
    297
  5. Ben Voigt
    Replies:
    8
    Views:
    1,015
Loading...

Share This Page