tags:

views:

368

answers:

3

Is there a simple library to benchmark the time it takes to execute a portion of C code? What I want is something like:

int main(){
    benchmarkBegin(0);
    //Do work
    double elapsedMS = benchmarkEnd(0);

    benchmarkBegin(1)
    //Do some more work
    double elapsedMS2 = benchmarkEnd(1);

    double speedup = benchmarkSpeedup(elapsedMS, elapsedMS2); //Calculates relative speedup
}

It would also be great if the library let you do many runs, averaging them and calculating the variance in timing!

+1  A: 

In POSIX, try getrusage. The relevant argument is RUSAGE_SELF and the relevant fields are ru_utime.tv_sec and ru_utime.tv_usec.

lhf
A: 

There may be existing utilities that help with this, but I suspect most will use some kind of sampling or possibly injection. But to get specific sections of code timed, you will probably have to add in calls to a timer like you show in your example. If you are using Windows, then the high performance timer works. I answered a similar question and showed example code that will do that. There are similar methods for Linux.

Mark Wilkins
+3  A: 

Basically, all you want is a high resolution timer. The elapsed time is of course just a difference in times and the speedup is calculated by dividing the times for each task. I have included the code for a high resolution timer that should work on at least windows and unix.

#ifdef WIN32

#include <windows.h>
double get_time()
{
    LARGE_INTEGER t, f;
    QueryPerformanceCounter(&t);
    QueryPerformanceFrequency(&f);
    return double(t.QuadPart)/double(f.QuadPart);
}

#else

#include <sys/time.h>
#include <sys/resource.h>

double get_time()
{
    struct timeval t;
    struct timezone tzp;
    gettimeofday(&t, &tzp);
    return t.tv_sec + t.tv_usec*1e-6;
}

#endif
Joe
Wallclock time (as returned by `gettimeofday`) may not be that useful - `clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...)` will often be what's wanted there.
caf
@caf: A program that uses very little CPU time but spends a lot of time doing blocking I/O or waiting for asynchronous I/O can still be perceived by users to be slow. Both CPU time and wall clock time are important.
bk1e
Yes, that's why I qualified my comment with the weasel-words "may" and "often" ;) By the way, if wallclock time *is* desired, then `clock_gettime(CLOCK_MONOTONIC, ...)` is a better option, because unlike `gettimeofday` it won't be affected by changes to the system clock during the timing interval.
caf
In my typical usage, I only care about wall clock time, because I am doing resource intensive things. I'm not sure how clock_gettime works with multi-threading, but that seems like an area where wall clock time is the only accurate measure.
Joe