Comments on: Profiling Code Using clock_gettime

By: jg4545

jg4545 — Sun, 13 Nov 2011 21:08:03 +0000

Hi,
Like Chandim I tried the code but the second count is not incrementing even if I use sleep(3).
Can anyone help please?
The program works fine if I use CLOCK_MONOTONIC.

Thanks.

By: newbee

newbee — Mon, 03 Oct 2011 15:53:40 +0000

hi again,
After research, I found that iosream compile on g++,
but new problem came.

I got error look like below :

‘timespec’ does not name of a type
in function ‘int main()’;
timespec,CLOCK_PROCESS_CPUTIME_ID’, time1, clock_gettime, time2, diff was not declare on this scope

thanks in advance.

By: newbee

newbee — Mon, 03 Oct 2011 13:11:50 +0000

hi,
I’m very new in c,
while try to understand you explanation, I got this

fatal error: iostream: No such file or directory

I’m use mingw and codeblock to run you example,
would you like to explain to me what wrong ?

thanks in advance.

By: Mike

Mike — Sat, 20 Aug 2011 01:21:14 +0000

Hi,

I am trying to use your code with gcc. I did add -lrt in the command line, however it doesnt seem like its recognizing timespec structure. As a result its erroring out. Any clue? Also, where can I find my time.h and sys/time.h files? I’m running on my company server.

thanks
-M.

By: JRG

JRG — Sat, 30 Jul 2011 21:06:12 +0000

Jomat, your version contains needless sophistries and your sample as written will leak memory. Your code demonstrates very poor programming practice by forcing memory to be freed at a different level from which it was allocated.

One assumes you are attempting to optimize Mr. Rutenberg’s original code. Your attempt is both unnecessary and ineffective. gcc has automatically optimized out the temporaries in both the parameters and the return value for many years now. Your modifications are not only unnecessary, but they failed to achieve your aim, since the malloc() call consumes many more cycles than your conversion to pointers saves. Mr. Rutenberg’s code is better than yours.

By: Chandim

Chandim — Tue, 15 Mar 2011 07:02:27 +0000

Guy,

Your example given for the clock_gettime(CLOCK_PROCESS_CPUTIME_ID) is not working when the sec count is increased. Is is something with the function call. I always get the sec count as 0 even I put a sleep between the start and end of clock_getttime functions.
Can you explain this?

Thanks in advance.

By: Jomat

Jomat — Fri, 11 Feb 2011 02:20:15 +0000

If you are using Linux (Eg Ubuntu) and programming in C (GCC Compiler) you need to perform the following changes:

static struct timespec*
clock_diff(struct timespec *start, struct timespec *end) {
struct timespec *diff;

if(!(diff = malloc(sizeof(struct timespec)))) {
return NULL;
} else if((end->tv_nsec – start->tv_nsec) tv_sec = end->tv_sec – start->tv_sec – 1;
diff->tv_nsec = 1000000000 + end->tv_nsec – start->tv_nsec;
} else {
diff->tv_sec = end->tv_sec – start->tv_sec;
diff->tv_nsec = end->tv_nsec – start->tv_nsec;
}
return diff;
}

// Where you want to use it
struct timespec start, stop;

// Start Counter
if(clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &start) < 0) {
goto return_failed;
}

// Put here whatever you want to test here

// Where you want to stop
if(clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &stop) diff = clock_diff(&start, &stop))) {
goto return_failed;
}

return_failed:
// Free whatever you need to free in case it crashes…
return NULL;

By: Guy

Guy — Thu, 23 Dec 2010 20:26:42 +0000

It is possible. However, it’s very unlikely to happen to you. The exact time it will happen depends on the clock you choose. For the CLOCK_REALTIME you should expect it to happen in 2038, and for the other two clocks, CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID, it’s even less likely, as it will take 138 years.

By: Data

Data — Mon, 20 Dec 2010 11:06:38 +0000

tv_sec might be a 32 bit field, is it possible that this field will overflow? (i.e. reach its largest value and reset?) Shouldn’t you take this into consideration in your “diff” function?

By: Albert

Albert — Wed, 15 Dec 2010 15:59:21 +0000

Hi, it seems like CLOCK_PROCESS_CPUTIME_ID timer summarizes times spent by each thread. So that I can compute the
scalability = time(CLOCK_PROCESS_CPUTIME_ID)/
time(CLOCK_THREAD_CPUTIME_ID).
E.g.:
clock_gettime(CLOCK_PROCESS_CPUTIME_ID …);
clock_gettime(CLOCK_THREAD_CPUTIME_ID …);
#pragma omp parallel
{
// do mt-job here
}
clock_gettime(CLOCK_PROCESS_CPUTIME_ID …);
clock_gettime(CLOCK_THREAD_CPUTIME_ID …);

Is that a right conclusion?
At least on my Fedora13-64 I guess it is true.