clock() function

"Pushkar Pradhan" <pu*****@gri.msstate.edu> wrote in message
news:3F**************@gri.msstate.edu...

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" <mk******@mkwahler.net> schrieb im Newsbeitrag
news:tF****************@newsread4.news.pas.earthli nk.net...

"Pushkar Pradhan" <pu*****@gri.msstate.edu> wrote in message
news:3F**************@gri.msstate.edu...

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

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:tF****************@newsread4.news.pas.earthli nk.net...

"Pushkar Pradhan" <pu*****@gri.msstate.edu> wrote in message
news:3F**************@gri.msstate.edu...

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

"Robert Stankowic" <pc******@netway.at> wrote in message
news:3f***********************@newsreader02.highwa y.telekom.at...

"Mike Wahler" <mk******@mkwahler.net> schrieb im Newsbeitrag
news:tF****************@newsread4.news.pas.earthli nk.net...

"Pushkar Pradhan" <pu*****@gri.msstate.edu> wrote in message
news:3F**************@gri.msstate.edu...

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" <mk******@mkwahler.net> schrieb im Newsbeitrag
news:LU*****************@newsread4.news.pas.earthl ink.net...

"Robert Stankowic" <pc******@netway.at> wrote in message
news:3f***********************@newsreader02.highwa y.telekom.at...

"Mike Wahler" <mk******@mkwahler.net> schrieb im Newsbeitrag
news:tF****************@newsread4.news.pas.earthli nk.net...

"Pushkar Pradhan" <pu*****@gri.msstate.edu> wrote in message
news:3F**************@gri.msstate.edu...
> 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 wrote:

"Mike Wahler" <mk******@mkwahler.net> schrieb im Newsbeitrag
news:tF****************@newsread4.news.pas.earthli nk.net...

"Pushkar Pradhan" <pu*****@gri.msstate.edu> wrote in message
news:3F**************@gri.msstate.edu...

> 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

In <3f***********************@newsreader02.highway.te lekom.at> "Robert Stankowic" <pc******@netway.at> 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: Da*****@ifh.de

Pushkar Pradhan <pu*****@gri.msstate.edu> wrote in message news:<3F**************@gri.msstate.edu>...

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

"Mike Wahler" <mk******@mkwahler.net> wrote in message news:<tF****************@newsread4.news.pas.earthl ink.net>...

"Pushkar Pradhan" <pu*****@gri.msstate.edu> wrote in message
news:3F**************@gri.msstate.edu...

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

Pushkar Pradhan <pu*****@gri.msstate.edu> wrote in message news:<3F**************@gri.msstate.edu>...

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,

In <ff*************************@posting.google.com> ru**@webmail.co.za (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: Da*****@ifh.de

"Daniel Vallstrom" <Da**************@safelogic.se> wrote in message
news:17**************************@posting.google.c om...

"Mike Wahler" <mk******@mkwahler.net> wrote in message news:<tF****************@newsread4.news.pas.earthl ink.net>...

"Pushkar Pradhan" <pu*****@gri.msstate.edu> wrote in message
news:3F**************@gri.msstate.edu...

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

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" <pc******@netway.at> wrote in message
news:3f***********************@newsreader02.highwa y.telekom.at...

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

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <3f***********************@newsreader02.highway.te lekom.at> "Robert Stankowic" <pc******@netway.at> 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

Pushkar Pradhan <pu*****@gri.msstate.edu> 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) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <3f***********************@newsreader02.highway.te lekom.at> "Robert Stankowic" <pc******@netway.at> 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: Da*****@ifh.de

"Dan Pop" <Da*****@cern.ch> wrote in message
news:bm**********@sunnews.cern.ch...

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <3f***********************@newsreader02.highway.te lekom.at> "Robert Stankowic" <pc******@netway.at> 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" <mk******@mkwahler.net> writes:

"Dan Pop" <Da*****@cern.ch> wrote in message
news:bm**********@sunnews.cern.ch...

[...]

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) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

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

Yeah, from our favorite legalistic point of view that would be the
thing to hope for. I forgot;p

Daniel Vallstrom

Dan

"Keith Thompson" <ks*@cts.com> wrote in message news:lz************@cts.com...

"Mike Wahler" <mk******@mkwahler.net> writes:

"Dan Pop" <Da*****@cern.ch> wrote in message
news:bm**********@sunnews.cern.ch... [...]

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.

As long as it doesn't wrap to (clock_t)(-1), then it is fine. You'll
likely want to cast it to unsigned of the same size. If you detect
a clock() result of (clock_t)(-1), then all bets are off.

For a 32-bit clock_t type, you are stuck with 32-bit resolution
unless there is also a non-standard library call than can return
the number of wrap-arounds since the last call to clock(). (Thus,
effectively increasing the size to 64-bits.)
Probably be best solution in this case would be to make clock_t a
64-bit type (as it already is on some platforms).

That is probably a better solution that would conform
to the standard.

"Mike Wahler" <mk******@mkwahler.net> wrote in message news:<64*****************@newsread3.news.pas.earth link.net>...

"Dan Pop" <Da*****@cern.ch> wrote in message
news:bm**********@sunnews.cern.ch...

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...> 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?

No. Read the whole clock() description. Dan even explicitly say
in the text you quote above that almost anything goes since it
can be argued that it's "the implementation's best approximation".
He just *hopes* that implementations return -1 since a literal
reading perhaps suggests that. An other approach, and IMO better,
would be to note that wraparounds could be legal, that they are
more useful and common practice, and therefor use wraparounds.

Compare e.g. with the issue if implementations are allowed to
return memory back to the OS (which IMO they certainly are).
You have to make up your own mind.
"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?
The clock type is often signed and then it would wrap to e.g. -2^31.
Anyway, I bet that most or all of the compilers you consider
conforming do wraparounds.
Daniel Vallstrom


-Mike

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

>Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...
>> 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)
^^^^^^^^^^^^^^

Yeah, from our favorite legalistic point of view that would be the
thing to hope for. I forgot;p

It's also from a practical point of view. Imagine that the second clock_t
value you obtain is greater than the first one: how can you tell whether
wraparound occured and how many times between the two clock_t calls?

What is better: no answer or a hopelessly wrong answer?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

>Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...
>> 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)
^^^^^^^^^^^^^^
Yeah, from our favorite legalistic point of view that would be the
thing to hope for. I forgot;p

It's also from a practical point of view. Imagine that the second clock_t
value you obtain is greater than the first one: how can you tell whether
wraparound occured and how many times between the two clock_t calls?

By requiring that clock calls are made frequent enough. In the OP's
case he would have to call the clock time-out library function at
least every 36 or 72 minutes.
What is better: no answer or a hopelessly wrong answer?
No answer is much better than a possibly wrong answer if the risk of
answering wrong is high enough. But that's not the case here. In all
programs I have used wraparounds in, there is no real risk of missing
a (relevant) wraparound.

Though, perhaps the implementors of clock did wraparounds because it
was the easiest solution rather than something thought through. And
then the standard writers felt that they had to allow the practice?
Daniel Vallstrom

Dan

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

>Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...
>> In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:
>>
>> >Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...
>> >> 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)
>> ^^^^^^^^^^^^^^
>
>Yeah, from our favorite legalistic point of view that would be the
>thing to hope for. I forgot;p
It's also from a practical point of view. Imagine that the second clock_t
value you obtain is greater than the first one: how can you tell whether
wraparound occured and how many times between the two clock_t calls?

By requiring that clock calls are made frequent enough. In the OP's
case he would have to call the clock time-out library function at
least every 36 or 72 minutes.

How frequent is "frequent enough" in a *portable* program? Is the
standard preventing an implementation from wrapping around after 1 second?
After 1 millisecond?

What is better: no answer or a hopelessly wrong answer?

No answer is much better than a possibly wrong answer if the risk of
answering wrong is high enough. But that's not the case here. In all
programs I have used wraparounds in, there is no real risk of missing
a (relevant) wraparound.

Is this a property of the programs (see my remark above) or of the
actual implementations you have used?
Though, perhaps the implementors of clock did wraparounds because it
was the easiest solution rather than something thought through. And
then the standard writers felt that they had to allow the practice?

The C standard certainly tried to accomodate existing practice, but it
also did its best to discourage wraparounds.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

>Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...
>> In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:
>>
>> >Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...
>> >> 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)
>> ^^^^^^^^^^^^^^
>
>Yeah, from our favorite legalistic point of view that would be the
>thing to hope for. I forgot;p

It's also from a practical point of view. Imagine that the second clock_t
value you obtain is greater than the first one: how can you tell whether
wraparound occured and how many times between the two clock_t calls?
By requiring that clock calls are made frequent enough. In the OP's
case he would have to call the clock time-out library function at
least every 36 or 72 minutes.

How frequent is "frequent enough" in a *portable* program? Is the
standard preventing an implementation from wrapping around after 1 second?
After 1 millisecond?

I have only claimed that it's "fairly portable" (which might
be a contradiction in terms). What do you propose if someone
needs large clock timings? I could try some non-C solution
which I don't know how to do and which probably would be
system specific and limited? Or I could fairly easily code
some C module to keep track of the wraparounds and which
will work on all systems I'm coding for.

What is better: no answer or a hopelessly wrong answer?
No answer is much better than a possibly wrong answer if the risk of
answering wrong is high enough. But that's not the case here. In all
programs I have used wraparounds in, there is no real risk of missing
a (relevant) wraparound.

Is this a property of the programs (see my remark above) or of the
actual implementations you have used?

Both. From the C compiler/system you need that it really
uses wraparounds and that the wraparounds don't occur too
frequently. Then you have to check the clock frequently
enough in the code that needs the timers. It's also
dependent on the input to the program.

This obviously isn't a perfect solution but for me at
least it seemed better than the alternative --- but
that might be because I'm too ignorant of what the
alternative would be.
Daniel Vallstrom

Though, perhaps the implementors of clock did wraparounds because it
was the easiest solution rather than something thought through. And
then the standard writers felt that they had to allow the practice?

The C standard certainly tried to accomodate existing practice, but it
also did its best to discourage wraparounds.

Dan

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

How frequent is "frequent enough" in a *portable* program? Is the
standard preventing an implementation from wrapping around after 1 second?
After 1 millisecond?
I have only claimed that it's "fairly portable" (which might
be a contradiction in terms). What do you propose if someone
needs large clock timings?

The best solution is to remove the need for large clock timings. It has
always worked for me.
I could try some non-C solution
which I don't know how to do and which probably would be
system specific and limited?
Your own solution is implementation-specific and limited, even if it only
uses standard library functions.

Yes, when the standard library provides no satisfactory solution, there
is nothing wrong with using an implementation-specific solution.
Or I could fairly easily code
some C module to keep track of the wraparounds and which
will work on all systems I'm coding for.
This being comp.lang.c, a solution is considered portable when it relies
only on that the C specification guarantees. Or the C specification
not only doesn't guarantee wraparounds, it even does its best to outlaw
them.

Furthermore, if you detect wraparound, how do you handle it in a
*portable* way, without knowing the range and signedness of clock_t?

Is this a property of the programs (see my remark above) or of the
actual implementations you have used?

Both. From the C compiler/system you need that it really
uses wraparounds and that the wraparounds don't occur too
frequently.

You need more than that. You also need the range of clock_t, which
neither the standard nor the implementation specifies (in a portable way).
Then you have to check the clock frequently
enough in the code that needs the timers.
Frequent checks alter the measurement, because they consume CPU time,
too.
This obviously isn't a perfect solution but for me at
least it seemed better than the alternative --- but
that might be because I'm too ignorant of what the
alternative would be.

The best alternative is to reduce the time interval being measured to
a reasonable value (usually something between 1 second and 10 minutes).
If this is really not possible, implementations usually provide timing
tools without the shortcomings of clock().

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <17**************************@posting.google.com > Da**************@safelogic.se (Daniel Vallstrom) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

How frequent is "frequent enough" in a *portable* program? Is the
standard preventing an implementation from wrapping around after 1 second?
After 1 millisecond?
I have only claimed that it's "fairly portable" (which might
be a contradiction in terms). What do you propose if someone
needs large clock timings?

The best solution is to remove the need for large clock timings. It has
always worked for me.

Sometimes that might not be possible though. E.g. I use large clock
timings in a SAT solver. The solver might get hard problems to solve and a
large time limit. More importantly one might want to try different solver
strategies a certain amount of time dependent on the total time limit.

I could try some non-C solution
which I don't know how to do and which probably would be
system specific and limited?

Your own solution is implementation-specific and limited, even if it only
uses standard library functions.

Agreed all along.

Yes, when the standard library provides no satisfactory solution, there
is nothing wrong with using an implementation-specific solution.
But the question is what is best, the C or non-C solution. As you
have pointed out the C solution makes many shady assumptions about
various things not guaranteed by the standard. But it might still be
preferable over a non-C solution if you for every actual effort to
support long clock timings for some system in a non-C way note that
the C solution would have worked just fine again.

I'm not necessarily advocating the C solution, since it's unsafe. But
if you can live with the unsafeness, the C solution might be much
easier than a non-C one, especially once you have some code for
handling long clock times.

Or I could fairly easily code
some C module to keep track of the wraparounds and which
will work on all systems I'm coding for.

This being comp.lang.c, a solution is considered portable when it relies
only on that the C specification guarantees. Or the C specification
not only doesn't guarantee wraparounds, it even does its best to outlaw
them.

Furthermore, if you detect wraparound, how do you handle it in a
*portable* way, without knowing the range and signedness of clock_t?

I'm not of course. IIRC I just tested for some typical cases and handled
them. Actually probably only the common 32 bits type, for both signed and
unsigned. For other clock_t types, the clock timing would only be accurate
until a wrap around occurs.

You see, it's getting worse for every question you ask;)

Is this a property of the programs (see my remark above) or of the
actual implementations you have used?

Both. From the C compiler/system you need that it really
uses wraparounds and that the wraparounds don't occur too
frequently.

You need more than that. You also need the range of clock_t, which
neither the standard nor the implementation specifies (in a portable way).

Yup.

Then you have to check the clock frequently
enough in the code that needs the timers.

Frequent checks alter the measurement, because they consume CPU time,
too.

'Frequently enough' doesn't mean frequent. Typically just at least once
every 32 minutes. One would of course profile the program and make
sure that the clock checks take an insignificant amount of time.
Daniel Vallstrom

This obviously isn't a perfect solution but for me at
least it seemed better than the alternative --- but
that might be because I'm too ignorant of what the
alternative would be.

The best alternative is to reduce the time interval being measured to
a reasonable value (usually something between 1 second and 10 minutes).
If this is really not possible, implementations usually provide timing
tools without the shortcomings of clock().

Dan

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <ff*************************@posting.google.com> ru**@webmail.co.za (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.

no, there isn't. but it is possible, at the start of the program,
to *establish* a point of reference for the 2 tmies returned by
these functions. once you have a base reference, and you know
how many times clock() wraps around in a certain time interval,
(say, once every 36 mins), then you can always use time(), check
if the return minus the last return of time() is greater than
the wraparound time, and then use clock() to get the finer granularity.

its not clean, its not neat, but it is possible, no ?

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

if i still had it, i would :-)

of course, as it was written a long time ago, it might have
used a platform function anyway, or made assumptions about
the platform. if i had the time, i'd try to write it again.

goose,

In <ff**************************@posting.google.com > ru**@webmail.co.za (goose) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bm**********@sunnews.cern.ch>...

In <ff*************************@posting.google.com> ru**@webmail.co.za (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.

no, there isn't. but it is possible, at the start of the program,
to *establish* a point of reference for the 2 tmies returned by
these functions.

What do you mean?
once you have a base reference, and you know
how many times clock() wraps around in a certain time interval,
(say, once every 36 mins), then you can always use time(), check
If your code is relying on such information, then it is no longer
portable.
if the return minus the last return of time() is greater than
the wraparound time, and then use clock() to get the finer granularity.
There is NO way to combine time() and clock(), as they return completely
different times. Imagine that your program is running together with 9
other programs, all 10 being CPU-bound. The time interval reported by
time() will be about 10 times as large as the time interval reported by
clock().

Things are even hairier if the system load is variable during the
interval (which is quite common in practice, when sharing a system with
other people).
its not clean, its not neat, but it is possible, no ?

Is it? You have produced no *valid* argument and no code.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

>>> >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.
no, there isn't. but it is possible, at the start of the program,
to *establish* a point of reference for the 2 tmies returned by
these functions.

What do you mean?

once you have a base reference, and you know
how many times clock() wraps around in a certain time interval,
(say, once every 36 mins), then you can always use time(), check

If your code is relying on such information, then it is no longer
portable.

if the return minus the last return of time() is greater than
the wraparound time, and then use clock() to get the finer granularity.

There is NO way to combine time() and clock(), as they return completely
different times. Imagine that your program is running together with 9
other programs, all 10 being CPU-bound. The time interval reported by
time() will be about 10 times as large as the time interval reported by
clock().

You don't need to combine them. Check clock() and time() periodically.
Compute the difference between the last call to clock() and this
one, and add it to a running sum in a variable with enough range
to handle the sum with reasonable precision and range (e.g. long
double, or use a bignum package). Compute the difference between
the last call to time() and this one. If it's longer than the
fastest possible wraparound time (e.g. 36 minutes above), you *MIGHT*
have blown it and your result should be considered possibly inaccurate.
If it's not, you should have reasonable accuracy.
Things are even hairier if the system load is variable during the
interval (which is quite common in practice, when sharing a system with
other people).

In the above situation it doesn't get hairier, but you might
actually get an accurate answer even if you're not sure it is accurate.

Now, about computing the wraparound time: you know that difftime()
returns the difference of two times in units of seconds, and you
know that the difference of two clock_t values is in units of
(1.0/CLOCKS_PER_SEC) seconds. Further, it is a reasonable guess
that if clock_t is signed (which you can test at runtime) and if
sizeof(clock_t) is equal to one (or more) of sizeof(short),
sizeof(int), sizeof(long), or sizeof(long long), the maximum value
of a clock_t is very likely equal to the corresponding SHRT_MAX,
INT_MAX, LONG_MAX, or LLONG_MAX. If it's unsigned you can determine
the maximum value by setting a clock_t variable to (clock_t)-1,
then assigning that to some variable with bigger range, such as
long double. Now, how much is that maximum value divided by
CLOCKS_PER_SEC in seconds? It's OK if you guess low.

Now, you might get in trouble if your program can be heavily
multi-threaded (no, I'm not talking about a thread-aware program,
I'm talking about the compiler dividing the program into threads
on its own) by a smart compiler (and is running on, for example,
a kilo-processor array) and clock_t time in seconds goes by faster
than time_t time.

Gordon L. Burditt

In <bn********@library2.airnews.net> go***********@sneaky.lerctr.org (Gordon Burditt) writes:

You don't need to combine them. Check clock() and time() periodically.
What exactly "periodically" means? How do you know when it's time to
check them?
Compute the difference between the last call to clock() and this
one, and add it to a running sum in a variable with enough range
to handle the sum with reasonable precision and range (e.g. long
double, or use a bignum package). Compute the difference between
the last call to time() and this one. If it's longer than the
fastest possible wraparound time (e.g. 36 minutes above), you *MIGHT*
have blown it and your result should be considered possibly inaccurate.
If it's not, you should have reasonable accuracy.

Things are even hairier if the system load is variable during the
interval (which is quite common in practice, when sharing a system with
other people).

In the above situation it doesn't get hairier, but you might
actually get an accurate answer even if you're not sure it is accurate.

Now, about computing the wraparound time: you know that difftime()
returns the difference of two times in units of seconds, and you
know that the difference of two clock_t values is in units of
(1.0/CLOCKS_PER_SEC) seconds.

Doesn't help much if the wraparound time is less than one second, does it?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

Dan Pop wrote:

In <bn********@library2.airnews.net> go***********@sneaky.lerctr.org
(Gordon Burditt) writes:

You don't need to combine them. Check clock() and time() periodically.

What exactly "periodically" means? How do you know when it's time to
check them?

You can find out when it's time to check them by checking clock() and time()
periodically.

<g,d&r>

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton