clock()

[roberts.noah]

Ok, so I am trying to establish how boost.timer works and I try a few
things and afaict it doesn't. So I open the header to see why and run
some tests to establish what is going on and it all boils down to the
clock() function. Here is the code:


#include <iostream>
#include <cstdlib>

int main(void)
{
boost::timer tmr;


sleep(15);

std::cout << std::clock() << std::endl;

return 0;
}


That program always outputs "0". Documentation on clock() says that it
should return clock ticks since program started, which with the 15
second sleep that should be plenty. I don't understand.

 

[examples.smith]

The clock() function returns an approximation of processor time used by
the program.

but sleep() function not use processor time.

 

[JetSnaiL]

(e-mail address removed)
Ok, so I am trying to establish how boost.timer works and I try
fe

things and afaict it doesn't. So I open the header to see why an ru
some tests to establish what is going on and it all boils down t th
clock() function. Here is the code


#include <iostream
#include <cstdlib

int main(void

boost::timer tmr


sleep(15)

std::cout << std::clock() << std::endl

return 0



That program always outputs "0". Documentation on clock() says tha i
should return clock ticks since program started, which with the 1
second sleep that should be plenty. I don't understand

#include <ctime
#include <cstdlib
#include <iostream

using namespace std

int main(

sleep(10)
cout << clock() << endl
return 0


Outputs "15"

 

[roberts.noah]

Ok, so I am trying to establish how boost.timer works and I try a
few



#include <ctime>
#include <cstdlib>
#include <iostream>

using namespace std;

int main()
{
sleep(10);
cout << clock() << endl;
return 0;
}


Outputs "15".

Well, I get 0.

 

[Default User]

Ok, so I am trying to establish how boost.timer works and I try a few
things and afaict it doesn't. So I open the header to see why and run
some tests to establish what is going on and it all boils down to the
clock() function. Here is the code:

1. You aren't using clock() correctly. From the C99 draft standard:

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

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.


2. The clock() function measures process time, not wall time. You
reference sleep(), but that is NOT a standard function and we can't
really say anything about it. Probably comp.unix.programmer would be
better. Try it with calls to time() and difftime().





Brian

 

[KeithSpook]

Ok, so I am trying to establish how boost.timer works and I try a few
things and afaict it doesn't. So I open the header to see why and run
some tests to establish what is going on and it all boils down to the
clock() function. Here is the code:


#include <iostream>
#include <cstdlib>

int main(void)
{
boost::timer tmr;


sleep(15);

std::cout << std::clock() << std::endl;

return 0;
}


That program always outputs "0". Documentation on clock() says that it
should return clock ticks since program started, which with the 15
second sleep that should be plenty. I don't understand.

There seems to be differences between certain implementations of
clock(). Microsoft
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_clock.asp)
says that clock() returns the number of ticks since the process
started, while Solaris 9 man pages state that it returns the number of
ticks of CPU time since the last call to clock(). (So try calling it
at the beginning of your program...).

So all though it's a "standard C library call", it seems (to me) to be
rather implementation dependent, at least for the time being.

~KS

 

[Victor Bazarov]

[..]
2. The clock() function measures process time, not wall time.

Tell it to those who wrote Visual C++ C run-time library. Maybe
they will learn something new.

V

 

[Default User]

[..]
2. The clock() function measures process time, not wall time.

Tell it to those who wrote Visual C++ C run-time library. Maybe
they will learn something new.

Well, that's what the standard says.

Indeed this little program (warning, contains VSC++ stuff) seems to
give the same value for wall and process time. I'm not sure if that
indicates a broken implementation of clock() or of Sleep(), the latter
being non-standard of course so "broken" is questionable regardless.

Of course, the standard says "best approximation to the processor time
used by the program", so maybe that's is the best.

#include <iostream>
#include <time.h>
#include <windows.h>

int main(void)
{
time_t start, end;

start = time(0);
clock();
Sleep(15*1000); // equivalent to unix sleep(15)
std::cout << clock()/CLOCKS_PER_SEC << std::endl;
end = time(0);
std::cout << difftime(end, start) << std::endl;

return 0;
}

Results:

15
15

A relatively equivalent program on Solaris/gnu gives:

0
15




Brian

 

[Default User]

[..]
2. The clock() function measures process time, not wall time.

Tell it to those who wrote Visual C++ C run-time library. Maybe
they will learn something new.

Thinking about it more, the standard says, "time used by the program".
I guess that it's not at all clear what that means. So my other
comments about it being "broken" aren't correct, one could consider the
total time since invokation or the actual CPU usage or some other
method and be equally valid.



Brian

 

[andy]

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.

Does anyone know what happens/is meant to happen if the clock overflows
between calls?

regards
Andy Little

 

[Victor Bazarov]

[..]
2. The clock() function measures process time, not wall time.

Tell it to those who wrote Visual C++ C run-time library. Maybe
they will learn something new.

Thinking about it more, the standard says, "time used by the program".
I guess that it's not at all clear what that means. So my other
comments about it being "broken" aren't correct, one could consider
the total time since invokation or the actual CPU usage or some other
method and be equally valid.

Yeah, yeah... They do provide GetProcessTimes or GetThreadTimes to
get the true CPU times used, but it seems that they are unable to
grasp what 'clock' is for or about. My speculation is that nobody
has told them. That's why I suggested you do it.

V

 

[roberts.noah]

Default User wrote:
[..]
2. The clock() function measures process time, not wall time.

Tell it to those who wrote Visual C++ C run-time library. Maybe
they will learn something new.

Thinking about it more, the standard says, "time used by the program".
I guess that it's not at all clear what that means. So my other
comments about it being "broken" aren't correct, one could consider
the total time since invokation or the actual CPU usage or some other
method and be equally valid.

Yeah, yeah... They do provide GetProcessTimes or GetThreadTimes to
get the true CPU times used, but it seems that they are unable to
grasp what 'clock' is for or about. My speculation is that nobody
has told them. That's why I suggested you do it.

Ok, this bothers me then that this class "timer" is part of boost. I
thought boost was supposed to be a peer reviewed library and this
class, which is dependent upon a function that could basically return
anything, seems too trivial and buggy to be included.

Not only that, but it uses C-Style casts.

 

[Default User]

Default User wrote:

Yeah, yeah... They do provide GetProcessTimes or GetThreadTimes to
get the true CPU times used, but it seems that they are unable to
grasp what 'clock' is for or about. My speculation is that nobody
has told them. That's why I suggested you do it.

I took your comment somewhat differently

It does seem like having a clock() that is more or less time() with
different granularity isn't all that useful, especially as it makes
standard programs run very differently on other systems.



Brian

 

[Default User]

Does anyone know what happens/is meant to happen if the clock
overflows between calls?

The C standard doesn't say. The POSIX standard has the following under
Application Usage:

The value returned by clock() may wrap around on some implementations.
For example, on a machine with 32-bit values for clock_t, it wraps
after 2147 seconds or 36 minutes.

Not much is specified about clock_t. Like time_t the only requirement
is that it be an "arithmetic type capable of representing times".

Theoretically it could be a signed integer and have UB on overflow, but
that would be a poor QOI.




Brian

 

[andy]

The C standard doesn't say. The POSIX standard has the following under
Application Usage:

The value returned by clock() may wrap around on some implementations.
For example, on a machine with 32-bit values for clock_t, it wraps
after 2147 seconds or 36 minutes.

Not much is specified about clock_t. Like time_t the only requirement
is that it be an "arithmetic type capable of representing times".

Theoretically it could be a signed integer and have UB on overflow, but
that would be a poor QOI.

Right but I seem to remember from assembler that in 2'sC you can take
(something like ) the absolute value of the difference between two
values to ignore overflow of an integer. You will need to detect a
rollover (by periodically detecting if the new value is < than the
previous 1, reseting between 2 > cycle half periods or otherwise only
doing this once per cycle) and add that on to the result returned since
startup, assuming some clock object with a ctor etc. (the return type
would have to be a (e.g) double of course) Actually its quite complex
to do it right. More so if you are guessing at the behaviour!

regards
Andy Little

 

[David Lindauer]

Right but I seem to remember from assembler that in 2'sC you can take
(something like ) the absolute value of the difference between two
values to ignore overflow of an integer. You will need to detect a
rollover (by periodically detecting if the new value is < than the
previous 1, reseting between 2 > cycle half periods or otherwise only
doing this once per cycle) and add that on to the result returned since
startup, assuming some clock object with a ctor etc. (the return type
would have to be a (e.g) double of course) Actually its quite complex
to do it right. More so if you are guessing at the behaviour!

The problem with that is that if you are really going to deal with standard
behavior, you can't assume 2'sC arithmetic...

David

 

[Rolf Magnus]

[..]
2. The clock() function measures process time, not wall time.

Tell it to those who wrote Visual C++ C run-time library. Maybe
they will learn something new.

Thinking about it more, the standard says, "time used by the program".

It says "the processor time used by the program".

I guess that it's not at all clear what that means. So my other
comments about it being "broken" aren't correct, one could consider the
total time since invokation or the actual CPU usage or some other
method and be equally valid.

"The processor time" is for me the actual CPU time used.

 

[andy]

The problem with that is that if you are really going to deal with standard
behavior, you can't assume 2'sC arithmetic...

I would be happy to adopt a divide and conquer approach, as there is
apparently no standard behaviour and the required spec seems reasonably
clear-cut. I'd be happy with just win32 and Linux 86. I havent met
any non 2'sC architecture though FWIW. I use clock as the basis of a
process timer for comparing code performance and while not life
critical it would be nice to sit down and get it right I guess. Its a
bit pathetic if it overflows every 30 minutes or so though, as that
gives an alarmingly high probability of it silently being wrong

regards
Andy Little

 

[andy]

Right but I seem to remember from assembler that in 2'sC you can take
(something like ) the absolute value of the difference between two
values to ignore overflow of an integer.

FWIW seems that difftime(later,earlier) might do just this

regards
Andy Little