17.3 Timing Complete Programs
With many programs, the first and
most logical step is simply to time how long the program takes to
execute from beginning to end. The total elapsed time is usually
called the program's wall-clock
time. While the wall-clock time reflects a
number of peripheral concerns such as system loads caused by other
users, it really is the bottom line. Ultimately, what you are really
interested in is how long you are going to have to wait for your
answers, and this is just what the wall-clock time measures.
Linux shells typically provide an internal timing command, usually
called
time. This command measures the total
execution time for a program when executed by the shell. Here is an
example with the bash shell:
[sloanjd@amy PROFILE]$ time ./demo
real 0m6.377s
user 0m5.350s
sys 0m0.010s
In this example, the program demo ran for a
total of 6.377 seconds. This number is the total elapsed time or
wall-clock time. Of that time, it spent 5.350 seconds executing the
user or non-kernel mode and another 0.010 seconds for system calls or
in kernel mode. The difference between the elapsed or real time and
the sum of the user and sys
times is time spent by the system doing computing for other tasks.
While most Unix shells provide a timing command, different shells
provide different levels of information. Here is the same program
timed under the C shell.
[sloanjd@amy PROFILE]$ csh
[sloanjd@amy ~/PROFILE]$ time ./demo
5.340u 0.000s 0:06.37 83.8% 0+0k 0+0io 65pf+0w
[sloanjd@amy ~/PROFILE]$ exit
exit
In addition to user, system, and wall-clock times, with the C shell
you also get percent of CPU time (83.8% in this example), shared and
unshared memory usage (0 and 0), block input and output operations (0
and 0), number of page faults (65), and number of swaps (0).
With some shells such as the Korn shell, there is another timer,
timex. timex, when used
with the -s option, provides still more
information. See the appropriate manpage for more details.
If you don't want to worry about shell-specific
commands, you can get pretty much the same information if you use
Linux's external time command.
[sloanjd@amy PROFILE]$ /usr/bin/time ./demo
5.32user 0.00system 0:06.51elapsed 81%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (66major+12minor)pagefaults 0swaps
And if you want to be overwhelmed with information, use the
-v option. (You might try
/bin/time if you aren't running
Linux.)
With MPICH or LAM/MPI you can run the time
command by simply inserting it on the command line before the call to
mpirun.
[sloanjd@amy PROFILE]$ time mpirun -np 4 rect
(This is not guaranteed to work with all versions of MPI.)
While you'll have already formed an opinion as to
whether your code is taking too long well before you get around to
timing it, time does let you to put some number
on your impression so that you'll sound more
professional when complaining about system performance. Also, the
difference between the wall-clock time and the time your program
takes will give you an idea of how much of the time is caused by your
code and how much of the time depends on system load. (Of course, if
you are timing an entire program, you needn't be
concerned about any code reordering caused by optimizing compilers.)
Finally, several timings with different input sizes can be used to
get a very rough idea of how your program will scale.
|