what's the best way to time your code?

[Pushkar Pradhan]

I need to time my blocked matrix multiply code to decide the optimal
block size.
I know two ways to do it: time() and clock() functions.
In order to get time is usec clock() must be divided by some CONSTANT
which defines the no. of clocks per sec.

Which one is more accurate or is there another best way?
Pushkar

 

[pete]

I need to time my blocked matrix multiply code to decide the optimal
block size.
I know two ways to do it: time() and clock() functions.
In order to get time is usec clock() must be divided by some CONSTANT
which defines the no. of clocks per sec.

clock() is for timing code.

 

[Mattia Belletti]

Il Sat, 27 Sep 2003 20:00:06 -0700, Pushkar Pradhan ha scritto:

Which one is more accurate or is there another best way?

I add my little suggestion: if you're on unix (I'm thinking of Linux, but
I suppose there are equivalents), remember the "time" command:

mat@jericho:~/prog/ocaml/it$ time ./make_sign < parole.txt > parole_signed.txt

real 0m11.593s
user 0m9.390s
sys 0m1.310s

it can be very useful, sometimes, to get infos about true time of
computation ("user" time). I do not know how much accurate is, but it
seemed to me fairly enough.

--
/**
* Mattia Belletti - Undergraduate student @ cs.unibo.it
* ICQ: 33292311 - email: (e-mail address removed)
* IRC: BluShine - site(s): http://cs.unibo.it/~mbellett
* Linux registered user 299762 @ Linux registered machine 213003
*/

 

[Thomas Matthews]

I need to time my blocked matrix multiply code to decide the optimal
block size.
I know two ways to do it: time() and clock() functions.
In order to get time is usec clock() must be divided by some CONSTANT
which defines the no. of clocks per sec.

Which one is more accurate or is there another best way?
Pushkar

Either function is not accurate enough to time a single
pass. The most accurate method is to use a platform specific
operating system call.

Otherwise, you would have to run enough iterations through your
code so you can use the clock() or time() functions.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Dan Pop]

Il Sat, 27 Sep 2003 20:00:06 -0700, Pushkar Pradhan ha scritto:


I add my little suggestion: if you're on unix (I'm thinking of Linux, but
I suppose there are equivalents), remember the "time" command:

mat@jericho:~/prog/ocaml/it$ time ./make_sign < parole.txt > parole_signed.txt

real 0m11.593s
user 0m9.390s
sys 0m1.310s

it can be very useful, sometimes, to get infos about true time of
computation ("user" time). I do not know how much accurate is, but it
seemed to me fairly enough.

You forgot to mention how this can be used to time only a certain part
of the program's code.

Dan

 

[Dan Pop]

I need to time my blocked matrix multiply code to decide the optimal
block size.
I know two ways to do it: time() and clock() functions.
In order to get time is usec clock() must be divided by some CONSTANT
which defines the no. of clocks per sec.

Which one is more accurate or is there another best way?

On most platforms, for most code timing purposes, time() is useless: it
doesn't tell you anything about how much time the CPU spent working on
your program.

clock() is the right function and CLOCKS_PER_SEC is the constant name.
Note, however, that despite the CLOCKS_PER_SEC value, the real resolution
of the clock() function is seldom less than 10 millisec. So, don't try
to use it on pieces of code that run in less than 1 CPU second.

Dan

 

[pete]

On most platforms, for most code timing purposes, time() is useless: it
doesn't tell you anything about how much time the CPU spent working on
your program.

clock() is the right function and CLOCKS_PER_SEC is the constant name.
Note, however, that despite the CLOCKS_PER_SEC value,
the real resolution
of the clock() function is seldom less than 10 millisec.
So, don't try
to use it on pieces of code that run in less than 1 CPU second.

I put fast test code in a loop that runs many times,
time the loops with the test code,
time the loops without the test code,
and then divide the difference in time,
by the number of loop cycles.

 

[Eric Sosman]

I put fast test code in a loop that runs many times,
time the loops with the test code,
time the loops without the test code,
and then divide the difference in time,
by the number of loop cycles.

This is a good approach, but requires some care to avoid
contamination by compiler optimizations. For example,

t0 = clock();
for (i = 0; i < 1000000; ++i) {
#if INCLUDE_THE_CODE
/* code being timed goes here */
#endif
}
t1 = clock();

.... may not work very well when INCLUDE_THE_CODE isn't defined,
because the compiler may optimize the whole loop away and replace
it with `i = 1000000;' -- or even with nothing at all, if `i'
isn't used subsequently.

A method that's worked for me is to use function pointers:

void no_op(void) {}

void for_real(void) {
/* code being timed goes here */
}

int main(int argc, char **argv) {
void (*func)(void) = (argc > 1) ? for_real : no_op;
...
t0 = clock();
for (i = 0; i < 1000000; ++i)
func();
t1 = clock();
...

.... so the compiler cannot predict which function the loop will
call. For an even greater comfort level, put the two called
functions in a different module and compile it separately from
the main program.

Someday, perhaps, compilers and linkers will become smart
enough to make even this technique fail (if anyone knows of an
implementation this smart, I'm sure we'd like to hear about it).
For the moment, though, it seems fairly robust.

 

[pete]

This is a good approach, but requires some care to avoid
contamination by compiler optimizations. For example,

t0 = clock();
for (i = 0; i < 1000000; ++i) {
#if INCLUDE_THE_CODE
/* code being timed goes here */
#endif
}
t1 = clock();

... may not work very well when INCLUDE_THE_CODE isn't defined,
because the compiler may optimize the whole loop away and replace
it with `i = 1000000;' -- or even with nothing at all, if `i'
isn't used subsequently.

A method that's worked for me is to use function pointers:

void no_op(void) {}

I do that too.

assert(p_l[0].f == nosort);

func_time = loop_time = doit(nosort, s2, s3, s1, N, 0);
for (function = 1; FUNCTIONS > function; ++function) {
func_time
= doit(p_l[function].f, s2, s3, s1, N, function)
- loop_time;
p_l[function].t += func_time;
if (func_time > TIME_MAX) {
break;
}
if (func_time > func_time_max) {
func_time_max = func_time;
}
}

 

[CBFalconer]

I do that too.

I suggest hiring some of Maxwells demons. When not busy timing
code they can be put to their original use, thus creating fuelless
heat engines and/or refrigerators.