ctime clock

[vsgdp]

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?

 

[Victor Bazarov]

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

 

[Markus Schoder]

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.

 

[osmium]

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().

 

[Default User]

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

 

[James Kanze]

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]

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]

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.

 

[Markus Schoder]

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)."

 

[Gennaro Prota]

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.)

 

[Greg Herlihy]

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

 

[Gennaro Prota]

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 )