Previous Section Table of Contents Next Section

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.

    Previous Section Table of Contents Next Section