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