ctime clock

Discussion in 'C++' started by vsgdp, May 6, 2007.

  1. vsgdp

    vsgdp Guest

    Hi,

    I was wondering if the clock function is reliable for long periods of
    time (maybe up to 10 hours).

    The reason I ask is because Stroustrup says "the clock() function is
    meant to measure intervals from a fraction of a second to a few
    seconds."

    In this case should I use time_t instead of clock_t?
    vsgdp, May 6, 2007
    #1
    1. Advertising

  2. vsgdp wrote:
    > I was wondering if the clock function is reliable for long periods of
    > time (maybe up to 10 hours).


    That is implementation- and platform-defined.

    > The reason I ask is because Stroustrup says "the clock() function is
    > meant to measure intervals from a fraction of a second to a few
    > seconds."
    >
    > In this case should I use time_t instead of clock_t?


    Maybe you should. Maybe you shouldn't. RTFM.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, May 6, 2007
    #2
    1. Advertising

  3. On Sun, 06 May 2007 08:21:56 -0700, vsgdp wrote:
    > Hi,
    >
    > I was wondering if the clock function is reliable for long periods of
    > time (maybe up to 10 hours).
    >
    > The reason I ask is because Stroustrup says "the clock() function is
    > meant to measure intervals from a fraction of a second to a few
    > seconds."
    >
    > In this case should I use time_t instead of clock_t?


    clock() measures processor time specifically. If you need that
    functionality there is no other standard way of doing this.

    --
    Markus
    Markus Schoder, May 6, 2007
    #3
  4. vsgdp

    osmium Guest

    "vsgdp" wrote:

    > I was wondering if the clock function is reliable for long periods of
    > time (maybe up to 10 hours).
    >
    > The reason I ask is because Stroustrup says "the clock() function is
    > meant to measure intervals from a fraction of a second to a few
    > seconds."
    >
    > In this case should I use time_t instead of clock_t?


    There is nothing in what he said that implies some kind of clock drift or
    something. He was merely pointing out the *intent* of having the function.
    Both the times you mention are derived from the same oscillator. If the
    granularity of time() is good enough, I would use it, it is portable without
    any effort on your part, whereas clock() depends on your OS. Also, look
    carefully at the definition of clock().
    osmium, May 6, 2007
    #4
  5. vsgdp

    Default User Guest

    vsgdp wrote:

    > Hi,
    >
    > I was wondering if the clock function is reliable for long periods of
    > time (maybe up to 10 hours).
    >
    > The reason I ask is because Stroustrup says "the clock() function is
    > meant to measure intervals from a fraction of a second to a few
    > seconds."
    >
    > In this case should I use time_t instead of clock_t?


    There are two issues.

    1. In many implementations of clock(), the return value will
    "roll-over" because the upper limit of clock_t will have been reached.
    You might not be able to accurately handle time differences of that
    size.

    2. clock() and time() are supposed to be measuring different things.
    One is processor time, the other wall time. As others said, read up on
    these two functions.


    You haven't explained what problem you're trying to solve, so it's
    somewhat difficult to advise.





    Brian
    Default User, May 6, 2007
    #5
  6. vsgdp

    James Kanze Guest

    On May 6, 5:21 pm, vsgdp <> wrote:

    > I was wondering if the clock function is reliable for long periods of
    > time (maybe up to 10 hours).


    It depends, but I don't think you should count on it. (On a 32
    bit Unix system, clock is only valid for up to a little over an
    hour after the first call.)

    > The reason I ask is because Stroustrup says "the clock() function is
    > meant to measure intervals from a fraction of a second to a few
    > seconds."


    He's being rather conservative; I'd count on it for up to about
    5 or 10 minutes.

    > In this case should I use time_t instead of clock_t?


    Maybe, but typically, they don't measure the same thing. The
    intent is that clock() measure the CPU time used by the
    process, if possible, where as time_t is required to be real
    (wall clock) time.

    --
    James Kanze (Gabi Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, May 6, 2007
    #6
  7. vsgdp

    James Kanze Guest

    On May 6, 6:32 pm, Markus Schoder <> wrote:
    > On Sun, 06 May 2007 08:21:56 -0700, vsgdp wrote:


    > > I was wondering if the clock function is reliable for long periods of
    > > time (maybe up to 10 hours).


    > > The reason I ask is because Stroustrup says "the clock() function is
    > > meant to measure intervals from a fraction of a second to a few
    > > seconds."


    > > In this case should I use time_t instead of clock_t?


    > clock() measures processor time specifically. If you need that
    > functionality there is no other standard way of doing this.


    What clock() measures is unspecified:). The intent is for it
    to measure processor time, to whatever degree that is possible
    on the underlying system. But even what is meant by "processor
    time" is rather vague: do you count CPU time used in system
    requests? or for managing paged memory? (If I'm not mistaken,
    most Unix systems use user time, and don't count CPU time in
    system requests, where as Windows uses wall clock
    time---presumably, the system doesn't have any mechanism for
    measuring actual processor time used by the process.)

    --
    James Kanze (Gabi Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, May 6, 2007
    #7
  8. vsgdp

    James Kanze Guest

    On May 6, 6:56 pm, "osmium" <> wrote:
    > "vsgdp" wrote:
    > > I was wondering if the clock function is reliable for long periods of
    > > time (maybe up to 10 hours).


    > > The reason I ask is because Stroustrup says "the clock() function is
    > > meant to measure intervals from a fraction of a second to a few
    > > seconds."


    > > In this case should I use time_t instead of clock_t?


    > There is nothing in what he said that implies some kind of clock drift or
    > something. He was merely pointing out the *intent* of having the function.


    I think that there's more to it than that. On 32 bit Unix
    systems, for example, the clock_t will "roll over" in a little
    over an hour (or less, if it is a signed type). Trying to use
    it for times in the range of 10 hours will result in undefined
    behavior in some cases, and totally random results in practice.

    > Both the times you mention are derived from the same oscillator.


    Maybe on some systems, but certainly not necessarily, and I'm
    not even sure that this is true on most widespread systems.

    --
    James Kanze (Gabi Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, May 6, 2007
    #8
  9. On Sun, 06 May 2007 12:38:06 -0700, James Kanze wrote:
    > On May 6, 6:32 pm, Markus Schoder <> wrote:
    >> On Sun, 06 May 2007 08:21:56 -0700, vsgdp wrote:

    >
    >> > I was wondering if the clock function is reliable for long periods of
    >> > time (maybe up to 10 hours).

    >
    >> > The reason I ask is because Stroustrup says "the clock() function is
    >> > meant to measure intervals from a fraction of a second to a few
    >> > seconds."

    >
    >> > In this case should I use time_t instead of clock_t?

    >
    >> clock() measures processor time specifically. If you need that
    >> functionality there is no other standard way of doing this.

    >
    > What clock() measures is unspecified:). The intent is for it to
    > measure processor time, to whatever degree that is possible on the
    > underlying system. But even what is meant by "processor time" is rather
    > vague: do you count CPU time used in system requests? or for managing
    > paged memory? (If I'm not mistaken, most Unix systems use user time,
    > and don't count CPU time in system requests, where as Windows uses wall
    > clock time---presumably, the system doesn't have any mechanism for
    > measuring actual processor time used by the process.)


    Actually the standard allows even a dummy implementation:

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

    --
    Markus
    Markus Schoder, May 6, 2007
    #9
  10. On 6 May 2007 12:38:06 -0700, James Kanze wrote:

    >What clock() measures is unspecified:). The intent is for it
    >to measure processor time, to whatever degree that is possible
    >on the underlying system. But even what is meant by "processor
    >time" is rather vague: do you count CPU time used in system
    >requests? or for managing paged memory? (If I'm not mistaken,
    >most Unix systems use user time, and don't count CPU time in
    >system requests, where as Windows uses wall clock
    >time---presumably, the system doesn't have any mechanism for
    >measuring actual processor time used by the process.)


    I'm afraid that's not the reason :) Not so long ago, I wrote several
    timer facilities based on requests made on the Boost list. I can't
    remember all the details but GetProcessTimes() was one of the
    available Win32 calls (FWIW, the reason I can't remember more details
    is that the whole thing involved the impossible and more than that...
    my first cut at implementing what people asked for ended up --for P4
    CPU's-- with assembly routines querying the Intel time stamp counters.
    Of course it was necessary to take cache misses into account, and
    --again, a request-- dynamic frequency adjustments, such as those
    performed via SpeedStep. Up to a point it was just fun, but we should
    all be happy that nothing like that end up into boost, or into any
    other library.)

    --
    Gennaro Prota
    https://sourceforge.net/projects/breeze/
    Gennaro Prota, May 7, 2007
    #10
  11. vsgdp

    Greg Herlihy Guest

    On May 6, 12:41 pm, James Kanze <> wrote:
    > On May 6, 6:56 pm, "osmium" <> wrote:
    >
    > > "vsgdp" wrote:
    > > > I was wondering if the clock function is reliable for long periods of
    > > > time (maybe up to 10 hours).
    > > > The reason I ask is because Stroustrup says "the clock() function is
    > > > meant to measure intervals from a fraction of a second to a few
    > > > seconds."
    > > > In this case should I use time_t instead of clock_t?

    > > There is nothing in what he said that implies some kind of clock drift or
    > > something. He was merely pointing out the *intent* of having the function.

    >
    > I think that there's more to it than that. On 32 bit Unix
    > systems, for example, the clock_t will "roll over" in a little
    > over an hour (or less, if it is a signed type). Trying to use
    > it for times in the range of 10 hours will result in undefined
    > behavior in some cases, and totally random results in practice.


    Not necessarily. Although Solaris defines CLOCKS_PER_SEC as 1000000,
    BSD systems (including OS X) define it as 100 - meaning that it would
    take 497 days for a 32-bit clock_t unsigned type to roll over on
    typical BSD Unix machine.

    Greg
    Greg Herlihy, May 7, 2007
    #11
  12. I should refrain from posting late in the night :)

    * Errata (majora) corrige: *

    While being prematurely asleep, on Mon, 07 May 2007 01:07:48 +0200,
    Gennaro Prota wrote:

    [all but the kitchen sink Boost experiment...]
    >Up to a point it was just fun,


    s/it was just fan/it was fun/

    >but we should all be happy that nothing like that end up into boost


    s/end up/ended up/ (alas, there's still a chance for something similar
    to get in; the issue is brought up again at irregulars intervals)

    s/boost/Boost (for early-morning consistency :))

    --
    Gennaro Prota
    https://sourceforge.net/projects/breeze/
    Gennaro Prota, May 7, 2007
    #12
    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,277
    louis lin
    Oct 28, 2003
  2. Replies:
    4
    Views:
    710
    Peter Alfke
    Apr 27, 2006
  3. Oplec
    Replies:
    2
    Views:
    508
    Oplec
    Oct 26, 2003
  4. Replies:
    5
    Views:
    2,151
    Ricardo
    Jun 23, 2006
  5. himassk
    Replies:
    1
    Views:
    1,226
    Paul Uiterlinden
    May 16, 2007
Loading...

Share This Page