Is there something else than clock()

[gizzmo]

In my code to get the CPU time I use the clock() function. The problem is that when my code runs for a long time (something like a day) it doesn't give reliable results - the clock function, that is. Actually, it sometimes gives me a negative value. Is there something else than this function? In addition, I also use omp_get_wtime(), to get the wall clock time, that comes with the openmp and this one works perfect. But at the end of my calculation I would like to know both the CPU time and wall clock time. So I am looking for a function that will give me the CPU time.

[eypros]

There is time():
http://www.cplusplus.com/reference/clibrary/ctime/time/
which I think uses the CPU time to tell how many second have passed since 1/1/1970. So you can use it to get the actual time

OK wrong answer. Ignore it. I didn't know what clock does...

[gizzmo]

It will give me the wall clock time, since it tells you how many seconds have passed since 1970. And I need CPU time. I should have mentioned that my application is multi-thread.

[cppabuser]

clock() should work fine. Use clock_t as a variable type for capturing moments in time and then after these are defined you caste your time values to DOUBLE to ensure everything works in harmony. Also clock_t is only a variable so like any variable it has it's limit as to how many increments it stores ... when it reaches the end it wraps around. The more ticks that CLOCKS_PER_SEC is set to, the sooner clock() will wrap. Single processors have little need for large CLOCKS_PER_SEC values. Apparently if CLOCKS_PER_SEC is set to one million it will wrap around every 2147 seconds (for 32 bit boxes). Knowing this you can use a variable to accumulate and hopefully match your cpu time with wall time.

[gizzmo]

That is exactly what is happening. Is there a function that does all that you have just wrote automatically?

[andywestken]

It's not really something else, but Boost does provide a timer class -- using clock() -- which can handle longer stretches of time. But the Boost documentation does warn:

The maximum measurable elapsed time may be as low as 596.5 hours...

http://www.boost.org/doc/libs/1_41_0/libs/timer/timer.htm

Andy

[cppabuser]

I looked into this a little more and saw this is common problem. The way I look at is your clock_t variable can count so high, so depending on how large your CLOCKS_PER_SEC is will determine how long your clock() function will last until it starts a new CYCLE again. This got me thinking that perhaps you can use the time function to track long running times but also keep the clock function going. You start and stop the two of them together. I cooked up a little code to demonstrate:

#include <stdio.h>
#include <time.h>
#include <Windows.h>
#include <math.h>

int main() {
clock_t cbegin, cend;
time_t tbegin, tend;
struct tm * timeinfo;
double dif;
double clocks;
double cycles;
double maxvalue;
double secondsexpired;
double secondspercycle;
double cyclesexpired;
double clocksexpired;
double clockcycles;

maxvalue = pow(2.0,sizeof(clock_t) * 8.0); // max clock_t value
cbegin = clock();
time(&tbegin);
timeinfo = localtime ( &tbegin );

printf("CBEGIN -> %f\n",(double)cbegin);
printf("TBEGIN -> %s\n",asctime(timeinfo));

Sleep(100000); // Let it accumulate some time - 100 seconds - go do something else, come back

cend = clock();
time(&tend);

// Calculate cycles from time function
dif = difftime(tend, tbegin); // number of seconds expired
secondspercycle = (double) maxvalue / CLOCKS_PER_SEC; // seconds/cycle
cyclesexpired = dif / secondspercycle; // cycles

// Now calculate cycles from clock function
clockcycles = ((double)(cend - cbegin)/ CLOCKS_PER_SEC) / secondspercycle;

printf("TIME function cycles is %f\n", cyclesexpired);
printf("CLOCK function cycles is %f\n", clockcycles);

return 0;
}

cyclesexpired will continue to accumulate far into the future where clockcycles will reset to zero once it hit's 1.00000 .... so you combine the integer part from cyclesexpired with the fractional part from clockcycles to get a more precise time. You can convert cycles back into normal time, (seconds, milliseconds, whatever). I'm not sure how much precision is lost using this method but I'm pretty sure the conversions are right. Maybe someone can improve upon this.