to find execution time

[vishnu mahendra]

cah you please tell me how to find the execution time of a program in c.


thank you in advance,
vishnu

 

[Richard Bos]

cah you please tell me how to find the execution time of a program in c.

Call clock() at the start of your program; call clock() at the end of
your program; subtract the two; divide by CLOCKS_PER_SEC. Not very
precise, probably, but it's as precise as ISO C gets.

Richard

 

[Dan Pop]

Call clock() at the start of your program; call clock() at the end of
your program; subtract the two; divide by CLOCKS_PER_SEC. Not very
precise, probably, but it's as precise as ISO C gets.

It's reasonably precise if the CPU time is not much shorter than 1
second and if you don't take Richard's advice ad litteram and divide
by a plain CLOCKS_PER_SEC. Convert it to float or double before
dividing by it.

Note that you get the CPU time used by the program this way. If you
need the real time instead, you have to use time() and difftime(), but
the usual resolution of this method is 1 second. For something better,
you need to use platform specific functions.

Dan

 

[Eric Sosman]

Call clock() at the start of your program; call clock() at the end of
your program; subtract the two; divide by CLOCKS_PER_SEC. Not very
precise, probably, but it's as precise as ISO C gets.

That's if "execution time" means "processor time."
If it instead means "elapsed time," the recipe is slightly
different: call time() at the start and end, and hand the
two values to difftime().

 

[GIR]

cah you please tell me how to find the execution time of a program in c.


thank you in advance,
vishnu

I don't know what platform you are writing for, but most "industrial
compilers" have an option to export your C file with the ASM code
included as comments.

What you do from there is get the user manual for your processor and
look up the used cycles per instruction. The Compiler we use (custom)
even includes the used memory.

If you know the XTAL of your processor (The ferquency is operates on,
probably mentioned in the user manual) you know how long 1 cycle is.

For example if you processor has an XTAL of 1MHz then 1 cycle takes 1
us (microsecond). Just multiply the total amount of cycles needed by
the XTAL and you got your execution time.

If you want further details then I suggest you look for a group
specific to your platform, this is just a group about the language C
and not hardware.

Good luck

 

[Kevin Goodsell]

I don't know what platform you are writing for, but most "industrial
compilers" have an option to export your C file with the ASM code
included as comments.

What you do from there is get the user manual for your processor and
look up the used cycles per instruction. The Compiler we use (custom)
even includes the used memory.

If you know the XTAL of your processor (The ferquency is operates on,
probably mentioned in the user manual) you know how long 1 cycle is.

OK, but this can be a very poor way to gauge execution time. Memory and
disk access, various interrupts, dynamic RAM refresh, branch prediction
failures, pipeline flushes, and many other things can affect the
execution speed. This varies from one architecture to the next, but in
general you can only know how fast a section of code is by carefully
timing it.

-Kevin

 

[Anupam Kapoor]

OK, but this can be a very poor way to gauge execution time. Memory
and disk access, various interrupts, dynamic RAM refresh, branch
prediction failures, pipeline flushes, and many other things can
affect the execution speed. This varies from one architecture to the
next, but in general you can only know how fast a section of code is
by carefully timing it.

some operating systems (linux/solaris that i am aware of) offer
nanosecond resolution monotonic timers. you can use those. but then
these measurements will have to be taken with a grain of salt. as
these might be skewed based on machine load, disk activity, usage
patterns etc. etc.

anupam

 

[Dan Pop]

I don't know what platform you are writing for, but most "industrial
compilers" have an option to export your C file with the ASM code
included as comments.

What you do from there is get the user manual for your processor and
look up the used cycles per instruction. The Compiler we use (custom)
even includes the used memory.

If you know the XTAL of your processor (The ferquency is operates on,
probably mentioned in the user manual) you know how long 1 cycle is.

For example if you processor has an XTAL of 1MHz then 1 cycle takes 1
us (microsecond). Just multiply the total amount of cycles needed by
the XTAL and you got your execution time.

This used to work 25 years ago, but it's useless on modern architectures.
A single cache miss may cost as much as 100 cpu cycles...

Dan

 

[GIR]

This used to work 25 years ago, but it's useless on modern architectures.
A single cache miss may cost as much as 100 cpu cycles...

Dan

To my knowledge that is the only accurate way of finding out how many
cycles a certain piece of code needs. And Like I said, it's platform
dependent. A good programmer always knows his/her system dynamics. If
for some reason the platform would introduce other ellements it's onto
the programmer to deal with these ellements. Like missed cache hits...
turn caching off.

Before mentoined methods of using timers or calling on the RTC are
susceptable to interrupts or are not accurate. I don't know how you
want to measure the performance of a piece of code just by looking at
the RTC...

 

[Dan Pop]

To my knowledge that is the only accurate way of finding out how many
cycles a certain piece of code needs. And Like I said, it's platform
dependent. A good programmer always knows his/her system dynamics. If
for some reason the platform would introduce other ellements it's onto
the programmer to deal with these ellements. Like missed cache hits...
turn caching off.

^^^^^^^^^^^^^^^^
You're either a patent idiot or a troll.

Dan

 

[vishnu mahendra]

Thanks a lot every body.
I really like this group.

thanks from,
vishnu

 

[Christopher Benson-Manica]

This used to work 25 years ago, but it's useless on modern architectures.
A single cache miss may cost as much as 100 cpu cycles...

100 cpu cycles? Why so high?

 

[J. J. Farrell]

I don't know what platform you are writing for, but most "industrial
compilers" have an option to export your C file with the ASM code
included as comments.

What you do from there is get the user manual for your processor and
look up the used cycles per instruction. The Compiler we use (custom)
even includes the used memory.

If you know the XTAL of your processor (The ferquency is operates on,
probably mentioned in the user manual) you know how long 1 cycle is.

For example if you processor has an XTAL of 1MHz then 1 cycle takes 1
us (microsecond). Just multiply the total amount of cycles needed by
the XTAL and you got your execution time.

This may have been a practical procedure in the early days of computers,
but for the last couple of decades it's been more or less useless. The
number of cycles required by each instruction is one minor factor in how
long the code will take to run on most modern systems.

The only realistic method for most people is to measure a large number
of iterations with the system in a controlled state.

 

[Dik T. Winter]

>
> 100 cpu cycles? Why so high?

Because the increase of memory speed did not catch up with the increase
in processor speed. How fast is memory nowadays? How many CPU cycles
does it take to get information from memory to the CPU?

 

[Richard Bos]

To my knowledge that is the only accurate way of finding out how many
cycles a certain piece of code needs.

The OP didn't ask about cycles, but about time. Those are far from the
same thing.

Richard

 

[Ken Asbury]

cah you please tell me how to find the execution time of a program in c.


thank you in advance,
vishnu

If this were comp.arch.embedded, I'd say that the cleanest way
is to change the state of an I/O pin as you enter and again when
you leave a section of code and measure the time on a 'scope.
However, IIRC there is (was?) a function in MS C++ to read a more
precise clock upon entering and again upon leaving, the delta
representing the elapsed time in (maybe?) milliseconds. It
took a while to find the function call but I'm sure someone
with a better memory here or in comp.arch.embedded will recall
it. Coffee breaks are hell.

HTH,
Ken Asbury

 

[GIR]

^^^^^^^^^^^^^^^^
You're either a patent idiot or a troll.

Dan

Uhu, it didn't occure to you that the language C isn't just for 8086
machines... there are architectures around which do allow a coder to
specify wether you want to enable caching. And once again like I said
it is platform dependent so if you want info on howto do it on a
certain platform then you will need to look that up in the group of
that platform.

comp.lang.c sais to me that this group is about the language C... I
think it's kinda ackward that you would automaticly presume that
everybody in here is programming for a 8086 architecture.

 

[GIR]

The OP didn't ask about cycles, but about time. Those are far from the
same thing.

Richard

At the start of this subthread I said:

 

[Kevin Goodsell]

Uhu, it didn't occure to you that the language C isn't just for 8086
machines... there are architectures around which do allow a coder to
specify wether you want to enable caching.

OK... but that would make the timing method you suggest *less* accurate.

-Kevin

 

[GIR]

OK... but that would make the timing method you suggest *less* accurate.

-Kevin

I think there's coliding views here. You guyz look at it from a
desktop POV where the OS handles alot of the stuff. I'm looking at it
from a system POV where you have to handle alot of stuff yourself and
thus know every little tiny detail of your system.

Because there is alot of interrupting and queuing going on in the
modern day OS the suggested timing via timers or RTC cannot and will
not be accurate. If you want to know how long a certain piece of code
(function, subroutine or method) exactly needs for it to complete it's
duties to only way to really know for sure is to look at it's cycles.