Going beyond this, if you need repeated runs of the code then you should first check that they run using simple debugging options (e.g. -g option), and then use optimizing compilers. If you have a clever compiler, then it will do everything for you and convert sloppy code into fast code. However, beware of over-optimizing the code. Some computers will convert do-loops into vectorized system calls, and these can actualy turn out to be slower! There may also be subtle effects depending upon cache size, register size etc in the code; sometimes if you unwrap loops the code can become slower.
You also have to be aware that some of the code may in fact violate standards, for instance fft.f suggests that you can call it with call fft(a(1),a(2),ntot,n,nspan,2) which violates some ANSI standards since then the two arrays in the subroutine overlap. The code mfft.tar seems to be correct, but for some reason the Makefile that came with it used a subscript testing compilation option which lead to an error.
A couple of other nasty possible traps that you may run into are where the origin is, and the effect of scaling. In general the "origin" is in the top left-hand corner (i.e. A(1,1) for a 2-D array), but you may find that some of the code uses the center (e.g. A(N/2+1,M/2+1) for a NxM array). It may also turn out that scaling is important - many computers have difficulty with very small numbers or very large ones, and the best arithmetic is tuned for numbers near 1. Also, the codes differ as to when, or if they scale the results. To check for both of the above a simple expediency is to fill a test array with 1's and see what the results are.