Benchmarking code with time.h?!

Development Boards MicroMod
1

Hello,

I have a piece of code that I need to benchmark on a Olimex SAM9-l9260 board running a Linux version 2.6.26.3-olimex (dimitar@lindev.vm) (gcc version 4.2.3 (Sourcery 8) kernel.

I tried to use time.h like this:

      printf("Computation start\n");
      t1 = clock();

      "DO THE STUFF"
      
      t2 = clock()-t1;
      printf("Computation end\n");
      
      printf ("%.6f\n", (double)(t2+0.0) / CLOCKS_PER_SEC);

But a get unresonable values :frowning:

Anybody have a clue if and how time.h works in this scenario (I don’t have to have processor time, wall-clock time is fine for me if that is the only one possible)…

Hope for luck!

Best/Carl

2

I can’t see anything wrong with it. I checked it with DJGPP gcc on my PC and it worked OK.

Leon

3

Carl’s routine is dividing by CLOCKS_PER_SECOND, unless the post was subsequently edited.

I do have a few questions:

  1. Exactly what is the nature of the unreasonable values? The routine is calculating the elapsed time in ticks per second (many times 1000 tps or 1 millisecond resolution). What values are you seeing? Any negative times?

  2. What type of variables are t1 and t2? They should be 32 bit signed values (or 64 bit if clock(), which isn’t always an int on every platform. If clock() returns a 64 bit value, to avoid the 2037 rollover issue, then t1 and t2 need to be 64 bit variables.

  3. Assuming the clock() is returning a signed value, it will eventually rollover (returning negative numbers). That means that t1 can be positive and t2 negative or vice-versa. You need to account for these cases, especially if the board is running for more than a few days.

  4. What is the value of CLOCKS_PER_SECOND? It may not be right for your board. You may have to calculate your own value by calling time(), waiting it for it to change, capture clock() in t1, wait for time() to change again, capture clock() in t2, subtract t2 from t1 to see the number of clocks per second.

4

CLOCKS_PER_SECOND doesn’t depend on the system clock, it’s defined in time.h as 91 (65536 ticks per hour).

Leon

5

Hi again,

Worked some more on this and have some reporting to do…

After a good nights sleep and some measuring with a normal stopwatch the values does not seem unreasonable anymore… The times I am measuring are in the range of a few seconds and using printf and a stopwatch I get values within 1/10:th of a second… So it seems ok…

On my platform CLOCKS_PER_SECOND has the value;

printf("Clops: %.6f\n",(double)CLOCKS_PER_SEC);

Clops: 1000000.000000

t1 and t2 were "clock_t"s and should hence cope with the values?!

So it seems to work fine.

Thanks!