|Efficient Execution Time Profiling ? email@example.com (1992-04-29)|
|Re: Efficient Execution Time Profiling ? firstname.lastname@example.org (1992-04-30)|
|Re: Efficient Execution Time Profiling ? email@example.com (1992-05-08)|
|Re: Efficient Execution Time Profiling ? firstname.lastname@example.org (1992-05-09)|
|Re: Efficient Execution Time Profiling ? email@example.com (1992-05-11)|
|From:||firstname.lastname@example.org (Thomas Fahringer)|
|Organization:||School of Computer Science, Carnegie Mellon|
|Date:||Wed, 29 Apr 1992 11:18:02 GMT|
I am currently building a conventional execution time profiler (very
similar to gprof) for F77 programs. The instrumented F77 program is
executed on a Sun Sparc Workstation.
For my profiler I want to have an option to instrument the profiled
program (in particular all procedure calls and loops) for execution times.
For my first trial I simply insert two system calls (ETIME - gets the
current system clock time in msec) before and after the program part to be
profiled, thus deriving execution times for specific program parts.
As expected I get incredible wrong values in particular for nested ETIME
calls (e.g. procedure call within a DO-loop, measuring both the procedure
call and DO-loop).
I figured out that gprof and prof derive very accurate execution times for
their instrumented programs.
Does anyone know how gprof or prof are deriving their execution times that
Does anyone know how I can improve my method of execution time profiling ?
I am eternal thankful for any kind of programs, article, reference, e-mail
address, etc. on this topic.
Thanks a lot in advance.
Thomas Fahringer Universitaet Wien
Institut fuer Statistik und Informatik
Bruenner Str. 72, 1210 Wien, Austria
e-mail: email@example.com fax: +43 1 39 26 47 224
[Unix systems use the monitor(3) routine which calls the profil(2) system
call, both documented in the FM. They build a histogram of program counters
sampling every time the hardware clock ticks. What do other systems do?
Return to the
Search the comp.compilers archives again.