tool to measure performance of written function

[cranium.2003]

hello,
If i wrote a C function then how to know that its costlier
in terms of processing time,execution, compilation.
I have written 2 functions for one problem but dont understand which
one is best from Opereating System's overhead point of view. so i want
tool that measure it.
If this is not right place to ask then tell me where to ask in any
other forum.

[Chris Croughton]

On 4 May 2005 07:23:10 -0700, cr**********@gm ail.com
<cr**********@g mail.com> wrote:

hello,
If i wrote a C function then how to know that its costlier
in terms of processing time,execution, compilation.
I have written 2 functions for one problem but dont understand which
one is best from Opereating System's overhead point of view. so i want
tool that measure it.
If this is not right place to ask then tell me where to ask in any
other forum.

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

/* declare my_function() */

#define LARGE_NUMBER 1000000

int main(void)
{
clock_t start, end;
time_t tstart, tend;
double t;
long i;

tstart = time(NULL);
start = clock();

for (i = 0; i < LARGE_NUMBER; ++i)
my_function();

end = clock();
tend = time(NULL);

t = (end - start) / (float)CLOCKS_P ER_SEC;

printf("process or time %g us, elapsed %g us\n",
t * 1e6 / LARGE_NUMBER,
difftime(tend, tstart) * 1e6 / LARGE_NUMBER);
}

This will give the times per invocation of the function.

Then repeat it with your other function instead of my_function().

You'll need to tweak the value of LARGE_NUMBER so that you get a
reasonable granularity, typically you'll want an execution time of at
least 100 seconds to get 2-digit resolution of the elapsed time (the
processor time returned by clock() is typically an order of magnitude or
better more accurate).

Note that on some systems clock() or time() might not work, or might be
of little use because of insufficient resolution (time() is often in
seconds, clock() is often in milliseconds but may only be updated 20
or fewer times a second). The elapsed time can also be affected by what
other processes (tasks) are running.

If you want to know the compilation time, get out a stopwatch, or ask in
a newsgroup about your operating system, that's outside standard C. If
you want to know how much time is spent in system functions, you
definitely need to ask in a newsgroup relevat to your system...

Chris C

[Eric Sosman]

Chris Croughton wrote:

clock_t start, end;
time_t tstart, tend;
double t;
[...]
t = (end - start) / (float)CLOCKS_P ER_SEC;

(Drifting slightly): Why `float' and not `double'?

In fact, there's even a faint possibility that
CLOCKS_PER_SEC could be `long double', so the cast to
mere `double' could lose precision. I'd suggest
writing

t = (end - start) / (CLOCKS_PER_SEC + 0.0);

as a way of ensuring that the calclulation is done in
"double or better" -- and if you really, truly wanted
only "float or better," you could write

t = (end - start) / (CLOCKS_PER_SEC + 0.0f);

Casting the overall result to `double' before the
assigment is optional, and might keep some compilers
from issuing warning diagnostics -- again, in the
unlikely event that CLOCKS_PER_SEC and/or `time_t' is
`long double'.

--
Er*********@sun .com

[Lawrence Kirby]

On Wed, 04 May 2005 14:13:20 -0400, Eric Sosman wrote:

Chris Croughton wrote:

clock_t start, end;
time_t tstart, tend;
double t;
[...]
t = (end - start) / (float)CLOCKS_P ER_SEC;

(Drifting slightly): Why `float' and not `double'?

In fact, there's even a faint possibility that
CLOCKS_PER_SEC could be `long double', so the cast to
mere `double' could lose precision. I'd suggest
writing

t = (end - start) / (CLOCKS_PER_SEC + 0.0);

However precision beyond double may not be important. You would also need
to make t long double to make use of it.

Lawrence

[Chris Croughton]

On Wed, 04 May 2005 14:13:20 -0400, Eric Sosman
<er*********@su n.com> wrote:

Chris Croughton wrote:

clock_t start, end;
time_t tstart, tend;
double t;
[...]
t = (end - start) / (float)CLOCKS_P ER_SEC;
(Drifting slightly): Why `float' and not `double'?

Since I had double t; no real reason (except that it saves a character
typing <g>).
In fact, there's even a faint possibility that
CLOCKS_PER_SEC could be `long double', so the cast to
mere `double' could lose precision. I'd suggest
writing

t = (end - start) / (CLOCKS_PER_SEC + 0.0);
Given the precision of CLOCKS_PER_SEC on most machines, I don't see the
point. You'd be into sub-microsecond accuracy before you ran off the
end of a float, and sub-nanosecond with a double (that's with the lowest
precision for float and double allowed by the standard).

Better would be to do

t = (double)(end - start) / CLOCKS_PER_SEC;

and avoid later programmers saying "but adding zero doesn't do anything
so I'll take it out" -- making the cast explicit indicates to
maintainers that there was a reason for it.
as a way of ensuring that the calclulation is done in
"double or better" -- and if you really, truly wanted
only "float or better," you could write

t = (end - start) / (CLOCKS_PER_SEC + 0.0f);
Again, I would rather use an explicit cast if I wanted it, it's more
obvious what it's doing.
Casting the overall result to `double' before the
assigment is optional, and might keep some compilers
from issuing warning diagnostics -- again, in the
unlikely event that CLOCKS_PER_SEC and/or `time_t' is
`long double'.

Indeed. I think I'll deal with that warning if it ever arises (many
programmers think that putting in casts to avoid warnings is bad anyway,
putting them in to avoid a possible warning which is unlikely to happen
is really going to annoy them)...

Chris C

[Eric Sosman]

Chris Croughton wrote:

On Wed, 04 May 2005 14:13:20 -0400, Eric Sosman
<er*********@su n.com> wrote:

Chris Croughton wrote:

clock_t start, end;
time_t tstart, tend;
double t;
[...]
t = (end - start) / (float)CLOCKS_P ER_SEC;
(Drifting slightly): Why `float' and not `double'?

Since I had double t; no real reason (except that it saves a character
typing <g>).

In fact, there's even a faint possibility that
CLOCKS_PER_SE C could be `long double', so the cast to
mere `double' could lose precision. I'd suggest
writing

t = (end - start) / (CLOCKS_PER_SEC + 0.0);

Given the precision of CLOCKS_PER_SEC on most machines, I don't see the
point. You'd be into sub-microsecond accuracy before you ran off the
end of a float, and sub-nanosecond with a double (that's with the lowest
precision for float and double allowed by the standard).

*Practical* arguments? *Real-world* reasons?! Hast
thou forgotten that thou'rt on comp.lang.c, where we worry
about things like padding bits in `short', eleven-bit `char',
and NULLs that aren't all-bits-zero? Pfui! Avaunt ye, thou
scalawag; thou'rt unworthy to be called Pedant! ;-)
[...]
Indeed. I think I'll deal with that warning if it ever arises (many
programmers think that putting in casts to avoid warnings is bad anyway,
putting them in to avoid a possible warning which is unlikely to happen
is really going to annoy them)...

I once encountered a compiler that warned about
"possible loss of precision" for `float f = 0.0;', and
actually had to turn the change-approval crank to "fix"
it with `float f = 0.0f;' ...

--
Er*********@sun .com

[pete]

Eric Sosman wrote:

Chris Croughton wrote:

Given the precision of CLOCKS_PER_SEC on most machines,
I don't see the
point. You'd be into sub-microsecond accuracy before
you ran off the
end of a float, and sub-nanosecond with a double
(that's with the lowest
precision for float and double allowed by the standard).

*Practical* arguments?

double is my default choice for floating point type.
I would need a special reason to use either float or long double.
I once encountered a compiler that warned about
"possible loss of precision" for `float f = 0.0;', and
actually had to turn the change-approval crank to "fix"
it with `float f = 0.0f;' ...

I like that warning.
I prefer to be mindful of expression types
and to match them up with each other whenever appropriate.

--
pete