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?

Advertisements

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

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

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

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

"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?

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

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

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.

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

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.

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?
>

"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?

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

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.

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

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!