Looking for a way to find CPU time to execute 
Author Message
 Looking for a way to find CPU time to execute

I need to find how much CPU time was taken to execute a
section of code/subroutine in a C program. I would appreciate
any leads in this direction. Does C has any call like secnds()
available in fortran ?

From:
Ravi



Fri, 15 Dec 1995 12:54:01 GMT  
 Looking for a way to find CPU time to execute

Quote:

> I need to find how much CPU time was taken to execute a
> section of code/subroutine in a C program. I would appreciate
> any leads in this direction. Does C has any call like secnds()
> available in Fortran ?

The standard C function clock() records CPU time (rather than wall clock time,
which is recorded by time()).  Comparing the values returned by clock() at two
points in the code will tell you how much CPU time has elapsed.

--
Steve Jameson                 Martin Marietta

                              Moorestown, New Jersey              
****************************************************************************
**  . . . but I do not love the sword for its sharpness, nor the arrow    **
**  for its swiftness, nor the warrior for his glory.  I love only that   **
**  which they defend . . .                                               **
**    -- Faramir, "The Two Towers"                                        **
****************************************************************************



Fri, 15 Dec 1995 19:40:03 GMT  
 Looking for a way to find CPU time to execute

Quote:

>> I need to find how much CPU time was taken to execute a
>> section of code/subroutine in a C program. I would appreciate
>> any leads in this direction. Does C has any call like secnds()
>> available in Fortran ?

>The standard C function clock() records CPU time (rather than wall clock time,
>which is recorded by time()).  Comparing the values returned by clock() at two
>points in the code will tell you how much CPU time has elapsed.

>--
>Steve Jameson                 Martin Marietta

>                              Moorestown, New Jersey              
>****************************************************************************
>**  . . . but I do not love the sword for its sharpness, nor the arrow    **
>**  for its swiftness, nor the warrior for his glory.  I love only that   **
>**  which they defend . . .                                               **
>**    -- Faramir, "The Two Towers"                                        **
>****************************************************************************

I tried to do same job some months ago. There are several alternatives
available. The program is the precision. Usually the smallest unit of profilabletime is a TICK which is sometimes too big to profile a small section of codes.

You may try:
(1) clock() as mentioned above.
(2) use profile features provided by most compiler and OS. In Unix, go
    from 'man cc' under -p option.
(3) use getresource(something like that). (Unix)
(4) use ALARM signal.

No matter what, you can not get beyond a TICK.




Sat, 16 Dec 1995 23:27:57 GMT  
 Looking for a way to find CPU time to execute

Quote:

>>> I need to find how much CPU time was taken to execute a
>>> section of code/subroutine in a C program.

>> Comparing the values returned by clock() at two
>>points in the code will tell you how much CPU time has elapsed.
>The [problem] is the precision. Usually the smallest unit of
>profilabletime is a TICK ...

Sampling will be reasonably accurate, if your code isn't time synchronised
and you get enough samples. If you have the source for enough of your program,
use profiling, and let the software take care of the complicated bits. If not,
use setitimer() and SIGVTALRM, and entry/exit routines in the interesting
bits to set a global to indicate what routines were running when the timer
interrupt occurred.

If you know what your tick rate is, use that, otherwise use the output of
'time' and divide the cpu time used by the total number of SIGVTALRM's to
get the rate. Multiply the rate by the number of signals intercepted within
the routine to get total run time, divide by the number of times you executed
it to get the per-call time.

If _I_ designed the computer, it'd have a faster clock.

Martin Golding   | sync, sync, sync, sank ... sunk:
DoD #0236        |  He who steals my code steals trash.
                 |   (Twas mine, tis his, and will be slave to thousands.)
A poor old decrepit Pick programmer. Sympathize at:



Sun, 17 Dec 1995 03:12:20 GMT  
 Looking for a way to find CPU time to execute

Quote:
>If _I_ designed the computer, it'd have a faster clock.

This may be a good idea for a MSDOS platform, where the clock interrupt driver
has almost nothing to do. Consider, however, the case of UNIX, where at each
clock interrupt the kernel has to update the timers of all processes and to
check if it's not the case to send a signal to a process whose timer has
expired and so on. Build a clock fast enough and the cpu will spend all its
cycles doing this kind of job.

Dan
--
Dan Pop
Tel:   +41.22.767.4534

Mail:  CERN - PPE, Bat. 20 R-054, CH-1211 Geneve 23, Switzerland



Sun, 17 Dec 1995 19:13:43 GMT  
 Looking for a way to find CPU time to execute

Quote:


> Golding) writes:

>>If _I_ designed the computer, it'd have a faster clock.

>This may be a good idea for a MSDOS platform, where the clock interrupt driver
>has almost nothing to do. Consider, however, the case of UNIX, where at each
>clock interrupt the kernel has to update the timers of all processes and to
>check if it's not the case to send a signal to a process whose timer has
>expired and so on. Build a clock fast enough and the cpu will spend all its
>cycles doing this kind of job.

There is no reason why Unix has to update the process timers at every clock
tick. It could run the clock at 10 times the rate and update the process
timers on every 10th tick. In fact it probably uses a priority queue so only
has to check against the earliest timeout in most circumstances. There would
just be a few operation which happen every tick.

-----------------------------------------


-----------------------------------------



Thu, 21 Dec 1995 05:38:28 GMT  
 Looking for a way to find CPU time to execute

Quote:
>There is no reason why Unix has to update the process timers at every clock
>tick. It could run the clock at 10 times the rate and update the process
>timers on every 10th tick. In fact it probably uses a priority queue so only
>has to check against the earliest timeout in most circumstances. There would
>just be a few operation which happen every tick.

Then you'd have nothing to gain by making the clock faster. The original idea
was to improve the granularity of clock() and of the process timers. The usage
of these timers is not only to generate a timeout signal, but also to be read
by a process, whenever the process needs that information.

Dan
--
Dan Pop
Tel:   +41.22.767.4534

Mail:  CERN - PPE, Bat. 20 R-054, CH-1211 Geneve 23, Switzerland



Thu, 21 Dec 1995 20:32:43 GMT  
 Looking for a way to find CPU time to execute

Quote:

>I need to find how much CPU time was taken to execute a
>section of code/subroutine in a C program. I would appreciate
>any leads in this direction. Does C has any call like secnds()
>available in Fortran ?

As an aside, if you want a good reference on timing code
execution, try "Efficient C" by Thomas Plum and Jim Brodie,
published by Plum-Hall.  I don't think it costs much (I got mine
free for review) and covers the subject well, with techniqes and
sample code to use.

--
=================================================================

 "I have stopped trying to get ahead so that I can
  cut down on the rate at which I am falling behind."
-----------------------------------------------------------------
 C Users Group (UK): For Serious C & C++ Users (Mail for details)
=================================================================



Thu, 21 Dec 1995 23:46:48 GMT  
 Looking for a way to find CPU time to execute

Quote:


> writes:

>>There is no reason why Unix has to update the process timers at every clock
>>tick. It could run the clock at 10 times the rate and update the process
>>timers on every 10th tick. In fact it probably uses a priority queue so only
>>has to check against the earliest timeout in most circumstances. There would
>>just be a few operation which happen every tick.

>Then you'd have nothing to gain by making the clock faster. The original idea
>was to improve the granularity of clock() and of the process timers. The usage
>of these timers is not only to generate a timeout signal, but also to be read
>by a process, whenever the process needs that information.

Updating the clock value would be one of the operation which happens every
tick. This is very cheap since it only need to be done for the current
running process.

-----------------------------------------


-----------------------------------------



Fri, 22 Dec 1995 02:51:04 GMT  
 Looking for a way to find CPU time to execute

Quote:

>>There is no reason why Unix has to update the process timers at every clock
>>tick. It could run the clock at 10 times the rate and update the process
>>timers on every 10th tick. In fact it probably uses a priority queue so only
>>has to check against the earliest timeout in most circumstances. There would
>>just be a few operation which happen every tick.
>Then you'd have nothing to gain by making the clock faster. The original idea
>was to improve the granularity of clock() and of the process timers. The usage
>of these timers is not only to generate a timeout signal, but also to be read
>by a process, whenever the process needs that information.

Well, I've never looked at the kernel code for processing the clock
interrupt, but I'd be really surprised if every process had to have
its timer updated every clock tick.  (I'd also be ashamed to be the
programmer that wrote such silly code.  :-)

An obvious implementation is for the running process to sample the
clock when it starts a timeslice and then subtract this value from the
current clock value to compute a difference when its timeslice ends.
This difference is added to the process' time accumlated in previous
timeslices.  The clock function call would make the same computation
(previously accumulated time plus the difference of the start of the
current timeslice and the current clock).

If the clock interrupt also handled checking for timeouts, then it
only needs to check the current running process' timeout.  The clock
interrupt code for all this is about 3 lines of C:

Clock_Interrupt ()
{
        Global_System_Time++;
        if (Global_System_Time > Current_Process_Start_Time + TIMESLICE)
                Run_Next_Process ();
        return;

Quote:
}

You could run this pretty fast before killing performance.  Of course,
the best implementation is for Global_System_Time to be a hardware
clock which is incremented autonomously and to have a hardware countdown
timer to implement timeout interrupts.

Sorry for getting off the C subject...

        -Lyle



Fri, 22 Dec 1995 22:50:18 GMT  
 Looking for a way to find CPU time to execute

Quote:
>An obvious implementation is for the running process to sample the
>clock when it starts a timeslice and then subtract this value from the
>current clock value to compute a difference when its timeslice ends.
>This difference is added to the process' time accumlated in previous
>timeslices.  The clock function call would make the same computation
>(previously accumulated time plus the difference of the start of the
>current timeslice and the current clock).
>If the clock interrupt also handled checking for timeouts, then it
>only needs to check the current running process' timeout.  The clock
>interrupt code for all this is about 3 lines of C:
>Clock_Interrupt ()
>{
>    Global_System_Time++;
>    if (Global_System_Time > Current_Process_Start_Time + TIMESLICE)
>            Run_Next_Process ();
>    return;
>}

My objection was not related to the scheduler, as your code suggests, but
to the fact that every process can request to the OS to be sent a signal
after a certain amount of time. After that, the process can simply sleep,
so it will not execute or compete for execution any more, so its timers will
never be updated, according to your implementation, so it will never receive
any signal. Have I missed anything?

Quote:
>Sorry for getting off the C subject...

Sorry, too,
Dan
--
Dan Pop
Tel:   +41.22.767.4534

Mail:  CERN - PPE, Bat. 20 R-054, CH-1211 Geneve 23, Switzerland


Sat, 23 Dec 1995 02:06:18 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. How to get CPU / CPU time for a process

2. How to get CPU / CPU time for a process

3. Looking for fast ways to build binary tree

4. Ways to reduce Link times?

5. Looking for a time function/code to add 1 second to time structure

6. How to get CPU time?

7. CPU time and #defines

8. CPU Time

9. CPU/time Consuming Operations?

10. Fine measurement of elapsed CPU time

11. cpu time

12. CPU TIME TAKEN BY SEECTION OF CODE.

 

 
Powered by phpBB® Forum Software