clock() function

  • Thread starter Pushkar Pradhan
  • Start date
P

Pushkar Pradhan

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

Mike Wahler

Pushkar Pradhan said:
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
 
R

Robert Stankowic

Mike Wahler said:
Pushkar Pradhan said:
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
 
M

Mike Wahler

Mike Wahler said:
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
 
M

Mike Wahler

Robert Stankowic said:
Mike Wahler said:
Pushkar Pradhan said:
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
 
R

Robert Stankowic

Mike Wahler said:
[....]

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

Dan Pop

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
 
T

Tim Prince

Robert said:
Mike Wahler said:
Pushkar Pradhan said:
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.
 
D

Daniel Vallstrom

Pushkar Pradhan said:
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
 
D

Daniel Vallstrom

[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
 
G

goose

Pushkar Pradhan said:
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,
 
D

Dan Pop

In said:
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
 
P

Pushkar Pradhan

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

Mike Wahler

Daniel Vallstrom said:
"Mike Wahler" <[email protected]> wrote in message
Pushkar Pradhan said:
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
 
M

Mike Wahler

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


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
 
D

Daniel Vallstrom

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
 
K

Keith Thompson

Pushkar Pradhan said:
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>
 
D

Dan Pop

In said:
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
 
M

Mike Wahler

Dan Pop said:
In <[email protected]>

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
 
K

Keith Thompson

Mike Wahler said:
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).
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top