definition of etime(3F)

David Hough sun!Eng!David.Hough
Tue Nov 16 14:11:30 PST 1993


Do you use etime for timing in Fortran?   It's been a part of f77-derived
Fortrans from at least 4.2 BSD, I think.   A currently contentious question is
how it should be defined on systems with multiple processors.   Here's a current
man page written long ago with only uniprocessors in mind:

==============================================================================

ETIME(3F)           FORTRAN LIBRARY ROUTINES            ETIME(3F)
NAME
     etime, dtime - return elapsed execution time

SYNOPSIS
     real function etime (time)
     real time(2)

     real function dtime (time)
     real time(2)

DESCRIPTION
     These two routines return elapsed runtime in seconds for the calling process.

     On the first call, dtime returns the elapsed time since  the start of execution.
     On the  second  and  subsequent  calls,  dtime  returns  the elapsed time since the last call to dtime.

     etime returns the elapsed time since the start of execution.
     The returned argument time contains user time in  the  first     element  and  system  time  in  the second element.  Elapsed     time, the returned value, is the  sum  of  user  and  system     time.

===============================================================================

The contention starts with the last line.   Even on a uniprocessor, the elapsed
(real) (wall clock) time is usually greater than the sum of user and system
times, especially if the system is heavily loaded.    On a multiprocessor that's
effectively exploiting multiple processors, the elapsed/real/wall clock time
is usually less than the user+system times summed over all involved processors.
If you are thinking of PC-style one-user one-job resource utilization, 
the wall clock time is of primary interest.   
If you are thinking of mainframe-style time-sharing resource utilization, 
the total of user+system time over all processors is of primary interest, since
for overall throughput 2x10 seconds costs as much as 1x20 seconds.

This gets commercially interesting when, rightly or wrongly,
people use etime for benchmarking multiprocessor systems.    

How should etime be defined on multiprocessors?   Has anybody intentionally
(as opposed to accidentally) redefined etime on their systems?

It might have been convenient if dtime/etime had originally been defined to
return wall clock time as the function value, with user and system time in
the argument arrays. But that last sentence in the man page,
defining the function value as
the sum of user and system time, argues against that particular revisionism.



More information about the Numeric-interest mailing list