clock() function

Discussion in 'C Programming' started by Pushkar Pradhan, Oct 9, 2003.

  1. I'm using clock() to time parts of my code
    e.g.
    clk1 = clock();
    /* code */
    clk2 = clock();
    /* calculate time in secs */
    ......
    clk1 = clock();
    /* code */
    clk2 = clock();
    /* calculate time in secs */

    I have to do this a couple of more times. I'm worried after reading the
    man page for clock() which says:
    USAGE
    The value returned by clock() is defined in microseconds for
    compatibility with systems that have CPU clocks with much
    higher resolution. Because of this, the value returned will
    wrap around after accumulating only 2147 seconds of CPU time
    (about 36 minutes).

    Does this mean if my code runs more than 36 mins. the timings calculated
    will be wrong?
    Pushkar Pradhan, Oct 9, 2003
    #1
    1. Advertising

  2. Pushkar Pradhan

    Mike Wahler Guest

    "Pushkar Pradhan" <> wrote in message
    news:...
    > I'm using clock() to time parts of my code
    > e.g.
    > clk1 = clock();
    > /* code */
    > clk2 = clock();
    > /* calculate time in secs */
    > .....
    > clk1 = clock();
    > /* code */
    > clk2 = clock();
    > /* calculate time in secs */
    >
    > I have to do this a couple of more times. I'm worried after reading the
    > man page for clock() which says:
    > USAGE
    > The value returned by clock() is defined in microseconds for
    > compatibility with systems that have CPU clocks with much
    > higher resolution. Because of this, the value returned will
    > wrap around after accumulating only 2147 seconds of CPU time
    > (about 36 minutes).
    >
    > Does this mean if my code runs more than 36 mins. the timings calculated
    > will be wrong?


    I understand it to be saying that the type of the value
    returned by your standard library implementation's 'clock()'
    function (type 'clock_t') can only represent time intervals
    of up to approximately 36 minutes before "wrapping" from its
    maximum value back to zero, and start counting up again.

    The specific underlying types and the values involved
    are implementation defined. I use "your" as abbreviation
    for "your implementation's" below:

    This means that the resolution of your 'clock()' function
    combined with the range of your type 'clock_t' results in
    a maximum range of 2147 seconds.

    This suggests to me that your 'clock_t' type is a 32-bit
    integer type, using 31 'value' bits, and one bit to indicate the
    sign for the -1 'error value', and that your 'CLOCKS_PER_SEC'
    macro is defined as 1000000 (one million), since the highest
    value representable with 31 bits is 2147483647, and
    2147483647 / 1000000 == 2147 (using integer division).

    This agrees with the statement above about 'defined in
    microseconds.' 2147 / 60 == 35.78, or about 36 minutes.

    As I say, the specifics of this stuff is implementation
    defined, and the above is my deduction. To determine
    for sure the exact limitations and behavior, you should
    write a small test program that uses 'sizeof(clock_t)',
    'CHAR_BIT', and 'CLOCKS_PER_SEC' to determine the exact
    values your implementation uses.

    I believe in your case the above test program would probably
    be only academic, though, because:

    About your specific question:

    If you store your elapsed time in a type 'clock_t'
    object then yes, your implementation limits this value
    to about 36 minutes before it "wraps" around back
    to zero.

    But you need not store the value in a type 'clock_t'
    object. Use a type with a range large enough for
    our anticipated needs, e.g. type 'double'. The required
    range of type 'double' is significantly higher than
    that of a 31 bit integer value.

    double start = (double)clock();
    double elapsed = 0;

    /* etc */

    elapsed = (double)clock() - start;


    HTH,
    -Mike
    Mike Wahler, Oct 9, 2003
    #2
    1. Advertising

  3. "Mike Wahler" <> schrieb im Newsbeitrag
    news:tF7hb.3975$...
    >
    > "Pushkar Pradhan" <> wrote in message
    > news:...
    > > I'm using clock() to time parts of my code
    > > e.g.
    > > clk1 = clock();
    > > /* code */
    > > clk2 = clock();
    > > /* calculate time in secs */
    > > .....
    > > clk1 = clock();
    > > /* code */
    > > clk2 = clock();
    > > /* calculate time in secs */
    > >
    > > I have to do this a couple of more times. I'm worried after reading the
    > > man page for clock() which says:
    > > USAGE
    > > The value returned by clock() is defined in microseconds for
    > > compatibility with systems that have CPU clocks with much
    > > higher resolution. Because of this, the value returned will
    > > wrap around after accumulating only 2147 seconds of CPU time
    > > (about 36 minutes).
    > >
    > > Does this mean if my code runs more than 36 mins. the timings calculated
    > > will be wrong?

    >


    [....]

    >
    > But you need not store the value in a type 'clock_t'
    > object. Use a type with a range large enough for
    > our anticipated needs, e.g. type 'double'. The required
    > range of type 'double' is significantly higher than
    > that of a 31 bit integer value.
    >
    > double start = (double)clock();
    > double elapsed = 0;
    >
    > /* etc */
    >
    > elapsed = (double)clock() - start;


    "The clock function returns the implementation’s best approximation to the
    processor
    time used by the program since the beginning of an implementation-defined
    era related
    only to the program invocation. To determine the time in seconds, the value
    returned by
    the clock function should be divided by the value of the macro
    CLOCKS_PER_SEC. If
    the processor time used is not available or its value cannot be represented,
    the function
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    returns the value (clock_t)-1"

    If I am not mistaken, the value _returned_ from clock() will (maybe, see
    below) wrap, so storing that in a double won't help, and the period the OP
    can use may even be much less than these 36 minutes, because the first call
    to clock() will most likely return a value > 0.
    I could not find anything in the standard about what happens if the maximum
    value representable in a clock_t is exceeded so I am not sure whether the
    value will actually wrap on every implementation, but the last sentence in
    the standard's description above suggests to me, that in this case the
    return value may be -1. (or is even _required_ to return -1... not sure
    about that from the wording).

    kind regards
    Robert
    Robert Stankowic, Oct 9, 2003
    #3
  4. Pushkar Pradhan

    Mike Wahler Guest

    Re: (followup) clock() function

    "Mike Wahler" <> wrote in message
    news:tF7hb.3975$...
    >
    > "Pushkar Pradhan" <> wrote in message
    > news:...
    > > I'm using clock() to time parts of my code
    > > e.g.
    > > clk1 = clock();
    > > /* code */
    > > clk2 = clock();
    > > /* calculate time in secs */
    > > .....
    > > clk1 = clock();
    > > /* code */
    > > clk2 = clock();
    > > /* calculate time in secs */
    > >
    > > I have to do this a couple of more times. I'm worried after reading the
    > > man page for clock() which says:
    > > USAGE
    > > The value returned by clock() is defined in microseconds for
    > > compatibility with systems that have CPU clocks with much
    > > higher resolution. Because of this, the value returned will
    > > wrap around after accumulating only 2147 seconds of CPU time
    > > (about 36 minutes).
    > >
    > > Does this mean if my code runs more than 36 mins. the timings calculated
    > > will be wrong?

    >
    > I understand it to be saying that the type of the value
    > returned by your standard library implementation's 'clock()'
    > function (type 'clock_t') can only represent time intervals
    > of up to approximately 36 minutes before "wrapping" from its
    > maximum value back to zero, and start counting up again.
    >
    > The specific underlying types and the values involved
    > are implementation defined. I use "your" as abbreviation
    > for "your implementation's" below:
    >
    > This means that the resolution of your 'clock()' function
    > combined with the range of your type 'clock_t' results in
    > a maximum range of 2147 seconds.
    >
    > This suggests to me that your 'clock_t' type is a 32-bit
    > integer type, using 31 'value' bits, and one bit to indicate the
    > sign for the -1 'error value', and that your 'CLOCKS_PER_SEC'
    > macro is defined as 1000000 (one million), since the highest
    > value representable with 31 bits is 2147483647, and
    > 2147483647 / 1000000 == 2147 (using integer division).
    >
    > This agrees with the statement above about 'defined in
    > microseconds.' 2147 / 60 == 35.78, or about 36 minutes.
    >
    > As I say, the specifics of this stuff is implementation
    > defined, and the above is my deduction. To determine
    > for sure the exact limitations and behavior, you should
    > write a small test program that uses 'sizeof(clock_t)',
    > 'CHAR_BIT', and 'CLOCKS_PER_SEC' to determine the exact
    > values your implementation uses.
    >
    > I believe in your case the above test program would probably
    > be only academic, though, because:
    >
    > About your specific question:
    >
    > If you store your elapsed time in a type 'clock_t'
    > object then yes, your implementation limits this value
    > to about 36 minutes before it "wraps" around back
    > to zero.
    >
    > But you need not store the value in a type 'clock_t'
    > object. Use a type with a range large enough for
    > our anticipated needs, e.g. type 'double'. The required
    > range of type 'double' is significantly higher than
    > that of a 31 bit integer value.
    >
    > double start = (double)clock();
    > double elapsed = 0;
    >
    > /* etc */
    >
    > elapsed = (double)clock() - start;



    After again reviewing the ISO standard, I have less
    confidence in my previous conclusion. As a matter
    of fact, the more I think about it, I don't think
    it's valid at all.

    Here is everything the standard has to say about 'clock()':
    (specifically, note 7.23.1 / 4)

    <begin ISO 9899 quote>

    7.23 Date and time <time.h>

    7.23.1 Components of time

    [...]

    2 The macros defined are NULL (described in 7.17); and

    CLOCKS_PER_SEC

    which expands to a constant expression with type clock_t (described
    below) that is the number per second of the value returned by the
    clock function.

    3 The types declared are size_t (described in 7.17);

    clock_t
    and

    time_t

    which are arithmetic types capable of representing times; and

    struct tm

    which holds the components of a calendar time, called the
    broken-down time.

    4 The range and precision of times representable in clock_t
    and time_t are implementation-defined.

    [...]

    7.23.2.1 The clock function

    Synopsis

    1 #include <time.h>
    clock_t clock(void);

    Description

    2 The clock function determines the processor time used.

    Returns

    3 The clock function returns the implementation’s best approximation
    to the processor time used by the program since the beginning of an
    implementation-defined era related only to the program invocation.
    To determine the time in seconds, the value returned by the clock
    function should be divided by the value of the macro CLOCKS_PER_SEC.
    If the processor time used is not available or its value cannot be
    represented, the function returns the value (clock_t)(-1). (266)

    (266) In order to measure the time spent in a program, the clock
    function should be called at the start of the program and its
    return value subtracted from the value returned by subsequent
    calls.

    <end ISO 9899 quote>


    Contrast (from above):

    4 The range and precision of times representable in clock_t
    and time_t are implementation-defined.

    with the quotation of your man page:

    "...Because of this, the value returned [by clock()] will
    wrap around after accumulating only 2147 seconds of CPU time
    (about 36 minutes)."

    It is not clear to me whether only actual value returned
    will wrap, and that some larger range is internally used
    by clock(), or if the internal range used has the stated
    limitation.

    The ISO standard is imo equally vague, only mentioning
    "the range and precision of times representable in
    clock_t and time_t", saying nothing about the type
    clock() uses internally to keep time between invocations
    or the range of that type.

    7.23.2.1 / 3 talks about an "implementation-defined era"
    but does not seem to say what unit of measurement is used
    to specify this "era". I'm assuming that falls under
    'implementation-defined' as well.


    So lacking (imo) definitive knowledge about this, it looks
    like we'd need an algorithm to figure out how far the
    value has 'wrapped' each time, and make adjustments,
    accumulating the adjusted values. Or use some other
    measurement tool with a range sufficient for your needs.
    'time()' probably gives a much larger range, but probably
    also a lesser resolution, so if you don't need the resolution
    provided by 'clock()' that might be an option.

    Perhaps someone else can give a more definitive answer
    and address my uncertainties stated above.

    Maybe I'm just too tired right now, and simply cannot
    see the obvious, it wouldn't be the first time. :)

    -Mike
    Mike Wahler, Oct 9, 2003
    #4
  5. Pushkar Pradhan

    Mike Wahler Guest

    "Robert Stankowic" <> wrote in message
    news:3f851422$0$16062$...
    >
    > "Mike Wahler" <> schrieb im Newsbeitrag
    > news:tF7hb.3975$...
    > >
    > > "Pushkar Pradhan" <> wrote in message
    > > news:...
    > > > I'm using clock() to time parts of my code
    > > > e.g.
    > > > clk1 = clock();
    > > > /* code */
    > > > clk2 = clock();
    > > > /* calculate time in secs */
    > > > .....
    > > > clk1 = clock();
    > > > /* code */
    > > > clk2 = clock();
    > > > /* calculate time in secs */
    > > >
    > > > I have to do this a couple of more times. I'm worried after reading

    the
    > > > man page for clock() which says:
    > > > USAGE
    > > > The value returned by clock() is defined in microseconds for
    > > > compatibility with systems that have CPU clocks with much
    > > > higher resolution. Because of this, the value returned will
    > > > wrap around after accumulating only 2147 seconds of CPU time
    > > > (about 36 minutes).
    > > >
    > > > Does this mean if my code runs more than 36 mins. the timings

    calculated
    > > > will be wrong?

    > >

    >
    > [....]
    >
    > >
    > > But you need not store the value in a type 'clock_t'
    > > object. Use a type with a range large enough for
    > > our anticipated needs, e.g. type 'double'. The required
    > > range of type 'double' is significantly higher than
    > > that of a 31 bit integer value.
    > >
    > > double start = (double)clock();
    > > double elapsed = 0;
    > >
    > > /* etc */
    > >
    > > elapsed = (double)clock() - start;

    >
    > "The clock function returns the implementation’s best approximation to the
    > processor
    > time used by the program since the beginning of an implementation-defined
    > era related
    > only to the program invocation. To determine the time in seconds, the

    value
    > returned by
    > the clock function should be divided by the value of the macro
    > CLOCKS_PER_SEC. If
    > the processor time used is not available or its value cannot be

    represented,
    > the function
    >

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > returns the value (clock_t)-1"
    >
    > If I am not mistaken, the value _returned_ from clock() will (maybe, see
    > below) wrap, so storing that in a double won't help, and the period the OP
    > can use may even be much less than these 36 minutes, because the first

    call
    > to clock() will most likely return a value > 0.
    > I could not find anything in the standard about what happens if the

    maximum
    > value representable in a clock_t is exceeded so I am not sure whether the
    > value will actually wrap on every implementation, but the last sentence in
    > the standard's description above suggests to me, that in this case the
    > return value may be -1. (or is even _required_ to return -1... not sure
    > about that from the wording).


    Yes, I reviewed what I wrote after I posted it, and posted
    a followup, with an ISO quote about clock(), saying essentially
    "wait a minute, still too many unanswered questions,
    I'm not sure." :)

    The bit about the -1 return only says "if value not available
    or cannot be represented". I think that 'wrapping' from
    max value to zero is outside this context, but I also
    am not certain.

    Maybe someone else will add more input about the standard.

    I do think that given what the OP's implementation
    documents, for it, an algorithm for "wrap adjustment"
    could probably be devised, if enough control can
    be exercised over the interval between 'clock()' polls.

    Thanks for your input.

    -Mike
    Mike Wahler, Oct 9, 2003
    #5
  6. "Mike Wahler" <> schrieb im Newsbeitrag
    news:LU8hb.4010$...
    >
    > "Robert Stankowic" <> wrote in message
    > news:3f851422$0$16062$...
    > >
    > > "Mike Wahler" <> schrieb im Newsbeitrag
    > > news:tF7hb.3975$...
    > > >
    > > > "Pushkar Pradhan" <> wrote in message
    > > > news:...
    > > > > I'm using clock() to time parts of my code

    [....]

    >
    > > "The clock function returns the implementation’s best approximation to

    the
    > > processor
    > > time used by the program since the beginning of an

    implementation-defined
    > > era related
    > > only to the program invocation. To determine the time in seconds, the

    > value
    > > returned by
    > > the clock function should be divided by the value of the macro
    > > CLOCKS_PER_SEC. If
    > > the processor time used is not available or its value cannot be

    > represented,
    > > the function
    > >

    > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > > returns the value (clock_t)-1"
    > >
    > > If I am not mistaken, the value _returned_ from clock() will (maybe, see
    > > below) wrap, so storing that in a double won't help, and the period the

    OP
    > > can use may even be much less than these 36 minutes, because the first

    > call
    > > to clock() will most likely return a value > 0.
    > > I could not find anything in the standard about what happens if the

    > maximum
    > > value representable in a clock_t is exceeded so I am not sure whether

    the
    > > value will actually wrap on every implementation, but the last sentence

    in
    > > the standard's description above suggests to me, that in this case the
    > > return value may be -1. (or is even _required_ to return -1... not sure
    > > about that from the wording).

    [....]

    > The bit about the -1 return only says "if value not available
    > or cannot be represented". I think that 'wrapping' from
    > max value to zero is outside this context, but I also
    > am not certain.


    Just one afterthought:
    I could imagine, that the return value of clock() wraps if clock()
    internally uses a counter of type clock_t, but is -1 if clock() internally
    uses a type with a higher range.
    But that is just a wild guess..
    Anyone a more precise statement? Dan Pop, Chris Torek, Richard Heathfield et
    al !??

    > I do think that given what the OP's implementation
    > documents, for it, an algorithm for "wrap adjustment"
    > could probably be devised, if enough control can
    > be exercised over the interval between 'clock()' polls.


    Maybe, but not easily. clock() measures CPU-time used for the running
    process and is AFAICS in no way related or synchronous to time(), so time()
    cannot be used to calculate how often clock() wrapped. If one wants just to
    time a loop, kind of "trial and error" approach may help, but for timing a
    more complex part of a program, where one cannot easily start with a time
    interval which is known to be less than the maximum clock_t value I have no
    idea.
    Again anyone a better statement?

    kind regards
    Robert
    Robert Stankowic, Oct 9, 2003
    #6
  7. Pushkar Pradhan

    Dan Pop Guest

    In <3f852bd2$0$27472$> "Robert Stankowic" <> writes:


    >Just one afterthought:
    >I could imagine, that the return value of clock() wraps if clock()
    >internally uses a counter of type clock_t, but is -1 if clock() internally
    >uses a type with a higher range.
    >But that is just a wild guess..
    >Anyone a more precise statement?


    The words: "the implementation's best approximation" effectively mean that
    an implementation can return *anything* from a clock() call, including a
    negative value, without having its conformance affected.

    I would hope that an implementation as described by the OP (i.e. most
    Unix implementations) constantly returns -1 after 36 minutes of CPU time,
    but I wouldn't bet on that. Especially after reading the Linux man page:

    BUGS
    ...
    Note that the time can wrap around. On a 32bit system
    where CLOCKS_PER_SEC equals 1000000 this function will
    return the same value approximately every 72 minutes.

    I've never needed to use clock() for intervals longer than a few minutes,
    so I've never tested its behaviour on overflow on any implementation.

    Most implementations provide better functions for this purpose, e.g. the
    Unix times (although it still uses clock_t, the conversion factor is no
    longer CLOCKS_PER_SEC, but sysconf(_SC_CLK_TCK), which has a reasonable
    value, reflecting the real resolution of these values).

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Oct 9, 2003
    #7
  8. Pushkar Pradhan

    Tim Prince Guest

    Robert Stankowic wrote:

    >
    > "Mike Wahler" <> schrieb im Newsbeitrag
    > news:tF7hb.3975$...
    >>
    >> "Pushkar Pradhan" <> wrote in message
    >> news:...
    >> > I'm using clock() to time parts of my code
    >> > e.g.
    >> > clk1 = clock();
    >> > /* code */
    >> > clk2 = clock();
    >> > /* calculate time in secs */
    >> > .....
    >> > clk1 = clock();
    >> > /* code */
    >> > clk2 = clock();
    >> > /* calculate time in secs */
    >> >
    >> > I have to do this a couple of more times. I'm worried after reading the
    >> > man page for clock() which says:
    >> > USAGE
    >> > The value returned by clock() is defined in microseconds for
    >> > compatibility with systems that have CPU clocks with much
    >> > higher resolution. Because of this, the value returned will
    >> > wrap around after accumulating only 2147 seconds of CPU time
    >> > (about 36 minutes).
    >> >
    >> > Does this mean if my code runs more than 36 mins. the timings
    >> > calculated will be wrong?

    >>

    >
    > [....]
    >
    >>
    >> But you need not store the value in a type 'clock_t'
    >> object. Use a type with a range large enough for
    >> our anticipated needs, e.g. type 'double'. The required
    >> range of type 'double' is significantly higher than
    >> that of a 31 bit integer value.
    >>
    >> double start = (double)clock();
    >> double elapsed = 0;
    >>
    >> /* etc */
    >>
    >> elapsed = (double)clock() - start;

    >
    > "The clock function returns the implementation’s best approximation to the
    > processor
    > time used by the program since the beginning of an implementation-defined
    > era related
    > only to the program invocation. To determine the time in seconds, the
    > value returned by
    > the clock function should be divided by the value of the macro
    > CLOCKS_PER_SEC. If
    > the processor time used is not available or its value cannot be
    > represented, the function
    >

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > returns the value (clock_t)-1"
    >
    > If I am not mistaken, the value _returned_ from clock() will (maybe, see
    > below) wrap, so storing that in a double won't help, and the period the OP
    > can use may even be much less than these 36 minutes, because the first
    > call to clock() will most likely return a value > 0.
    > I could not find anything in the standard about what happens if the
    > maximum value representable in a clock_t is exceeded so I am not sure
    > whether the value will actually wrap on every implementation, but the last
    > sentence in the standard's description above suggests to me, that in this
    > case the return value may be -1. (or is even _required_ to return -1...
    > not sure about that from the wording).
    >
    > kind regards
    > Robert

    The usual wrap behavior allows differences to be taken of intervals up to
    double the quoted value. For the larger intervals, the difference is
    wrapped into negative numbers, not to zero or an error value. Thus, it is
    possible to recover a meaningful value for an interval up to an hour by
    treating it as unsigned. As the documentation on my system says,
    Note that the time can wrap around. On a 32bit system
    where CLOCKS_PER_SEC equals 1000000 this function will
    return the same value approximately every 72 minutes.
    Neither the standard nor the previously quoted documentation provide
    assurance of that.
    IMHO clock() would be more useful if it returned a 64-bit type. Failing
    that, adherence to the posix value of CLOCKS_PER_SEC rather than the
    physical resolution appears misguided.
    --
    Tim Prince
    Tim Prince, Oct 9, 2003
    #8
  9. Pushkar Pradhan <> wrote in message news:<>...
    > I'm using clock() to time parts of my code
    > e.g.
    > clk1 = clock();
    > /* code */
    > clk2 = clock();
    > /* calculate time in secs */
    > .....
    > clk1 = clock();
    > /* code */
    > clk2 = clock();
    > /* calculate time in secs */
    >
    > I have to do this a couple of more times. I'm worried after reading the
    > man page for clock() which says:
    > USAGE
    > The value returned by clock() is defined in microseconds for
    > compatibility with systems that have CPU clocks with much
    > higher resolution. Because of this, the value returned will
    > wrap around after accumulating only 2147 seconds of CPU time
    > (about 36 minutes).
    >
    > Does this mean if my code runs more than 36 mins. the timings calculated
    > will be wrong?


    Yes, at least after 2*36 mins. The solution is to keep track of the
    wraparounds. It's not too hard. Btw, a solution to this fairly common
    problem would have been a good choice for that clc_ library project.

    Daniel Vallstrom
    Daniel Vallstrom, Oct 9, 2003
    #9
  10. "Mike Wahler" <> wrote in message news:<tF7hb.3975$>...
    > "Pushkar Pradhan" <> wrote in message
    > news:...
    > > I'm using clock() to time parts of my code
    > > e.g.
    > > clk1 = clock();
    > > /* code */
    > > clk2 = clock();
    > > /* calculate time in secs */
    > > .....
    > > clk1 = clock();
    > > /* code */
    > > clk2 = clock();
    > > /* calculate time in secs */
    > >
    > > I have to do this a couple of more times. I'm worried after reading the
    > > man page for clock() which says:
    > > USAGE
    > > The value returned by clock() is defined in microseconds for
    > > compatibility with systems that have CPU clocks with much
    > > higher resolution. Because of this, the value returned will
    > > wrap around after accumulating only 2147 seconds of CPU time
    > > (about 36 minutes).
    > >
    > > Does this mean if my code runs more than 36 mins. the timings calculated
    > > will be wrong?



    [snip]


    > About your specific question:
    >
    > If you store your elapsed time in a type 'clock_t'
    > object then yes, your implementation limits this value
    > to about 36 minutes before it "wraps" around back
    > to zero.
    >
    > But you need not store the value in a type 'clock_t'
    > object. Use a type with a range large enough for
    > our anticipated needs, e.g. type 'double'. The required
    > range of type 'double' is significantly higher than
    > that of a 31 bit integer value.
    >
    > double start = (double)clock();
    > double elapsed = 0;
    >
    > /* etc */
    >
    > elapsed = (double)clock() - start;


    This is no solution. The problem is clock() and just casting its return values
    won't magically fix it. You have to keep track of the wraparounds and where
    clock() is.


    Daniel Vallstrom

    >
    >
    > HTH,
    > -Mike
    Daniel Vallstrom, Oct 9, 2003
    #10
  11. Pushkar Pradhan

    goose Guest

    Pushkar Pradhan <> wrote in message news:<>...
    > I'm using clock() to time parts of my code
    > e.g.
    > clk1 = clock();
    > /* code */
    > clk2 = clock();
    > /* calculate time in secs */
    > .....
    > clk1 = clock();
    > /* code */
    > clk2 = clock();
    > /* calculate time in secs */
    >
    > I have to do this a couple of more times. I'm worried after reading the
    > man page for clock() which says:
    > USAGE
    > The value returned by clock() is defined in microseconds for
    > compatibility with systems that have CPU clocks with much
    > higher resolution. Because of this, the value returned will
    > wrap around after accumulating only 2147 seconds of CPU time
    > (about 36 minutes).
    >
    > Does this mean if my code runs more than 36 mins. the timings calculated
    > will be wrong?


    yes. if you want more than that at the resolution that clock()
    offers, just write your own timekeeping function, using a combination
    of clock() and time(). I've done this before, though i haven't the faintest
    clue what I've done with the source, if you have a bash at it, you'll find
    that its simple enough

    hth
    goose,
    goose, Oct 9, 2003
    #11
  12. Pushkar Pradhan

    Dan Pop Guest

    In <> (goose) writes:

    >yes. if you want more than that at the resolution that clock()
    >offers, just write your own timekeeping function, using a combination
    >of clock() and time(). I've done this before, though i haven't the faintest
    >clue what I've done with the source, if you have a bash at it, you'll find
    >that its simple enough


    I'm afraid that this is not possible at all (in a portable manner) because
    there is no connection whatsoever between the times returned by these two
    functions.

    Feel free to prove me wrong, by posting your code ;-)

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Oct 9, 2003
    #12
  13. I finally decided to replace clock() since it was causing so much confusion.
    I have replaced it with system specific gettimeofday() call which has
    enough resolution (microsecs) I think.

    Pushkar Pradhan wrote:
    > I'm using clock() to time parts of my code
    > e.g.
    > clk1 = clock();
    > /* code */
    > clk2 = clock();
    > /* calculate time in secs */
    > .....
    > clk1 = clock();
    > /* code */
    > clk2 = clock();
    > /* calculate time in secs */
    >
    > I have to do this a couple of more times. I'm worried after reading the
    > man page for clock() which says:
    > USAGE
    > The value returned by clock() is defined in microseconds for
    > compatibility with systems that have CPU clocks with much
    > higher resolution. Because of this, the value returned will
    > wrap around after accumulating only 2147 seconds of CPU time
    > (about 36 minutes).
    >
    > Does this mean if my code runs more than 36 mins. the timings calculated
    > will be wrong?
    >
    Pushkar Pradhan, Oct 9, 2003
    #13
  14. Pushkar Pradhan

    Mike Wahler Guest

    "Daniel Vallstrom" <> wrote in message
    news:...
    > "Mike Wahler" <> wrote in message

    news:<tF7hb.3975$>...
    > > "Pushkar Pradhan" <> wrote in message
    > > news:...
    > > > I'm using clock() to time parts of my code
    > > > e.g.
    > > > clk1 = clock();
    > > > /* code */
    > > > clk2 = clock();
    > > > /* calculate time in secs */
    > > > .....
    > > > clk1 = clock();
    > > > /* code */
    > > > clk2 = clock();
    > > > /* calculate time in secs */
    > > >
    > > > I have to do this a couple of more times. I'm worried after reading

    the
    > > > man page for clock() which says:
    > > > USAGE
    > > > The value returned by clock() is defined in microseconds for
    > > > compatibility with systems that have CPU clocks with much
    > > > higher resolution. Because of this, the value returned will
    > > > wrap around after accumulating only 2147 seconds of CPU time
    > > > (about 36 minutes).
    > > >
    > > > Does this mean if my code runs more than 36 mins. the timings

    calculated
    > > > will be wrong?

    >
    >
    > [snip]
    >
    >
    > > About your specific question:
    > >
    > > If you store your elapsed time in a type 'clock_t'
    > > object then yes, your implementation limits this value
    > > to about 36 minutes before it "wraps" around back
    > > to zero.
    > >
    > > But you need not store the value in a type 'clock_t'
    > > object. Use a type with a range large enough for
    > > our anticipated needs, e.g. type 'double'. The required
    > > range of type 'double' is significantly higher than
    > > that of a 31 bit integer value.
    > >
    > > double start = (double)clock();
    > > double elapsed = 0;
    > >
    > > /* etc */
    > >
    > > elapsed = (double)clock() - start;

    >
    > This is no solution. The problem is clock() and just casting its return

    values
    > won't magically fix it. You have to keep track of the wraparounds and

    where
    > clock() is.


    Yes, silly me, I realized that *after* I posted. :)

    -Mike
    Mike Wahler, Oct 9, 2003
    #14
  15. Pushkar Pradhan

    Mike Wahler Guest

    "Robert Stankowic" <> wrote in message
    news:3f852bd2$0$27472$...

    > Just one afterthought:
    > I could imagine, that the return value of clock() wraps if clock()
    > internally uses a counter of type clock_t, but is -1 if clock() internally
    > uses a type with a higher range.
    > But that is just a wild guess..
    > Anyone a more precise statement? Dan Pop, Chris Torek, Richard Heathfield

    et
    > al !??
    >
    > > I do think that given what the OP's implementation
    > > documents, for it, an algorithm for "wrap adjustment"
    > > could probably be devised, if enough control can
    > > be exercised over the interval between 'clock()' polls.

    >
    > Maybe, but not easily. clock() measures CPU-time used for the running
    > process and is AFAICS in no way related or synchronous to time(), so

    time()
    > cannot be used to calculate how often clock() wrapped.


    No, I wasn't thinking of time(), but of using 'emprical'
    knowledge of "expected"
    (yes, often a 'dirty word' in programming :) )
    approximate time needed for given
    portions of code, to make sure we call 'clock()' frequently
    enough. This is what I meant by "if enough control..."

    >If one wants just to
    > time a loop, kind of "trial and error" approach may help,


    :)

    > but for timing a
    > more complex part of a program, where one cannot easily start with a time
    > interval which is known to be less than the maximum clock_t value I have

    no
    > idea.
    > Again anyone a better statement?


    Not this time. Perhaps after I make a second try. :)


    -Mike
    Mike Wahler, Oct 9, 2003
    #15
  16. (Dan Pop) wrote in message news:<bm3j15$mu7$>...
    > In <3f852bd2$0$27472$> "Robert Stankowic" <> writes:
    >
    >
    > >Just one afterthought:
    > >I could imagine, that the return value of clock() wraps if clock()
    > >internally uses a counter of type clock_t, but is -1 if clock() internally
    > >uses a type with a higher range.
    > >But that is just a wild guess..
    > >Anyone a more precise statement?

    >
    > The words: "the implementation's best approximation" effectively mean that
    > an implementation can return *anything* from a clock() call, including a
    > negative value, without having its conformance affected.
    >
    > I would hope that an implementation as described by the OP (i.e. most
    > Unix implementations) constantly returns -1 after 36 minutes of CPU time,


    No! Why would you hope that? To teach those of us who use
    wraparounds a lesson?) In fact every system I know of use
    wraparounds! This admittedly doesn't include all that many
    systems but at least the common ones. It would be interesting
    to hear about systems that don't do wraparounds (and at the
    same time have a small clock type).

    Given that one needs clock timings greater than 36 mins, how should
    one achieve that? You could go for a non-C solution. That might get
    messy though if you code for many platforms? (I have never chosen
    that approach so I wouldn't know.) Or you could assume that clock()
    works in the usual and IMO useful way, which IMO includes
    wraparounds when they make sense, and use that to make some C
    library that is fairly portable.

    > but I wouldn't bet on that.


    I bet that there is a fair amount of C code using that clock() do
    wrap around on systems where that has been common practice.

    > Especially after reading the Linux man page:
    >
    > BUGS
    > ...
    > Note that the time can wrap around. On a 32bit system
    > where CLOCKS_PER_SEC equals 1000000 this function will
    > return the same value approximately every 72 minutes.
    >
    > I've never needed to use clock() for intervals longer than a few minutes,
    > so I've never tested its behaviour on overflow on any implementation.
    >
    > Most implementations provide better functions for this purpose, e.g. the
    > Unix times (although it still uses clock_t, the conversion factor is no
    > longer CLOCKS_PER_SEC, but sysconf(_SC_CLK_TCK), which has a reasonable
    > value, reflecting the real resolution of these values).


    But clock() with wraparounds is adequate, at least if you don't take
    into account the nuisance of coding some library to take care of the
    wraparounds and clock timings, which only needs to be done once
    anyway.


    Daniel Vallstrom


    >
    > Dan
    Daniel Vallstrom, Oct 9, 2003
    #16
  17. Pushkar Pradhan <> writes:
    > I finally decided to replace clock() since it was causing so much confusion.
    > I have replaced it with system specific gettimeofday() call which has
    > enough resolution (microsecs) I think.


    <OT>

    Note that gettimeofday() gives you the actual wall clock time, whereas
    clock() gives you the amount of CPU time used by your program. On any
    system with concurrent processes, these can be very different.

    As long as you're being system-specific, take a look at the times()
    function.

    </OT>

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
    Keith Thompson, Oct 10, 2003
    #17
  18. Pushkar Pradhan

    Dan Pop Guest

    In <> (Daniel Vallstrom) writes:

    > (Dan Pop) wrote in message news:<bm3j15$mu7$>...
    >> In <3f852bd2$0$27472$> "Robert Stankowic" <> writes:
    >>
    >>
    >> >Just one afterthought:
    >> >I could imagine, that the return value of clock() wraps if clock()
    >> >internally uses a counter of type clock_t, but is -1 if clock() internally
    >> >uses a type with a higher range.
    >> >But that is just a wild guess..
    >> >Anyone a more precise statement?

    >>
    >> The words: "the implementation's best approximation" effectively mean that
    >> an implementation can return *anything* from a clock() call, including a
    >> negative value, without having its conformance affected.
    >>
    >> I would hope that an implementation as described by the OP (i.e. most
    >> Unix implementations) constantly returns -1 after 36 minutes of CPU time,

    >
    >No! Why would you hope that?


    Because this is what the standard actually says:

    If the processor time used is not available or its value cannot
    ^^^^^^^^^^^^^^^^^^^
    be represented, the function returns the value (clock_t)(-1)
    ^^^^^^^^^^^^^^

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Oct 10, 2003
    #18
  19. Pushkar Pradhan

    Mike Wahler Guest

    "Dan Pop" <> wrote in message
    news:bm65t9$ekm$...
    > In <>

    (Daniel Vallstrom) writes:
    >
    > > (Dan Pop) wrote in message

    news:<bm3j15$mu7$>...
    > >> In <3f852bd2$0$27472$> "Robert

    Stankowic" <> writes:
    > >>
    > >>
    > >> >Just one afterthought:
    > >> >I could imagine, that the return value of clock() wraps if clock()
    > >> >internally uses a counter of type clock_t, but is -1 if clock()

    internally
    > >> >uses a type with a higher range.
    > >> >But that is just a wild guess..
    > >> >Anyone a more precise statement?
    > >>
    > >> The words: "the implementation's best approximation" effectively mean

    that
    > >> an implementation can return *anything* from a clock() call, including

    a
    > >> negative value, without having its conformance affected.
    > >>
    > >> I would hope that an implementation as described by the OP (i.e. most
    > >> Unix implementations) constantly returns -1 after 36 minutes of CPU

    time,
    > >
    > >No! Why would you hope that?

    >
    > Because this is what the standard actually says:
    >
    > If the processor time used is not available or its value cannot
    > ^^^^^^^^^^^^^^^^^^^
    > be represented, the function returns the value (clock_t)(-1)
    > ^^^^^^^^^^^^^^


    Should I understand this to mean that the 'wrapping'
    to zero described by the documentation posted by OP
    is not an allowed 'implementation-defined' component
    of 'clock()' behavior? "Zero" might not be of any
    practical use, but perhaps it *could* be called
    "best approximation" rather than "not representable".

    Are saying that a 'clock()' which "wraps" to zero is
    definitely not standard conforming?

    -Mike
    Mike Wahler, Oct 10, 2003
    #19
  20. "Mike Wahler" <> writes:
    > "Dan Pop" <> wrote in message
    > news:bm65t9$ekm$...

    [...]
    > > Because this is what the standard actually says:
    > >
    > > If the processor time used is not available or its value cannot
    > > ^^^^^^^^^^^^^^^^^^^
    > > be represented, the function returns the value (clock_t)(-1)
    > > ^^^^^^^^^^^^^^

    >
    > Should I understand this to mean that the 'wrapping'
    > to zero described by the documentation posted by OP
    > is not an allowed 'implementation-defined' component
    > of 'clock()' behavior? "Zero" might not be of any
    > practical use, but perhaps it *could* be called
    > "best approximation" rather than "not representable".
    >
    > Are saying that a 'clock()' which "wraps" to zero is
    > definitely not standard conforming?


    On one system I tested yesterday (Solaris 8), clock_t is a 32-bit
    signed integer type. The values returned by the clock() function wrap
    around to negative values. That's far more useful than returning -1
    after 2147 seconds, but it looks like it violates the standard.

    Probably be best solution in this case would be to make clock_t a
    64-bit type (as it already is on some platforms).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
    Keith Thompson, Oct 10, 2003
    #20
    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,283
    louis lin
    Oct 28, 2003
  2. Replies:
    4
    Views:
    715
    Peter Alfke
    Apr 27, 2006
  3. Replies:
    5
    Views:
    2,157
    Ricardo
    Jun 23, 2006
  4. himassk
    Replies:
    1
    Views:
    1,230
    Paul Uiterlinden
    May 16, 2007
  5. pankaj.goel
    Replies:
    6
    Views:
    932
    pankaj.goel
    Nov 25, 2008
Loading...

Share This Page