tool to measure performance of written function

C

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.
 
C

Chris Croughton

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_PER_SEC;

printf("processor 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
 
E

Eric Sosman

Chris said:
clock_t start, end;
time_t tstart, tend;
double t;
[...]
t = (end - start) / (float)CLOCKS_PER_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'.
 
L

Lawrence Kirby

Chris said:
clock_t start, end;
time_t tstart, tend;
double t;
[...]
t = (end - start) / (float)CLOCKS_PER_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
 
C

Chris Croughton

Chris said:
clock_t start, end;
time_t tstart, tend;
double t;
[...]
t = (end - start) / (float)CLOCKS_PER_SEC;

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

Since I had double t; no real reason (except that it saves a character
typing said:
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
 
E

Eric Sosman

Chris said:
Chris said:
clock_t start, end;
time_t tstart, tend;
double t;
[...]
t = (end - start) / (float)CLOCKS_PER_SEC;

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


Since I had double t; no real reason (except that it saves a character
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).

*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;' ...
 
P

pete

Eric said:
Chris Croughton wrote:

*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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,009
Latest member
GidgetGamb

Latest Threads

Top