Benchmarks on reading floating point values

[Delbert Franz <ddf at iqdotdt dot com>]

I have been experimenting with gfortran 4.3 from Debian Lenny and comparing
it with other compilers.  The application I  used computes unsteady flow in a network
of channels.  The river system I am modeling requires values at about 10,000 
locations.  The river system and the imposed boundary conditions are specified
in about 400 files comprised mainly of single-precision floating point numbers. 
I am reporting two times for each compiler.  The first is the setup time, mainly 
spent in opening, reading, and closing the 400 files.  The second, the compute 
time, is almost all computation with minimal output.  These were all run 
on an Acer Aspire One netbook (actually quite a capable CPU for its size):

lf95-- Version 6.2 of Lahey Fortran compiler--a bit out of date: latest CPU it knows is Pentium 4!
g95-- compiler from g95.org
gf-- gfortran 4.3 from Debian Lenny
if-- Intel compiler with support for the Atom CPU
Times in seconds

Compiler:       lf95                   g95                        gf                 if
           Setup     Compute     Setup     Compute          Setup    Compute   Setup    Compute
           ------    -------     -----     -------          -----    -------   ------   -------
           17.3       66.6       33.6      66.1             37.7     57.2      24.2     54.9

Conclusions:

1. Setup for g95 is essentially twice that for lf95.  This ratio appears to hold across
   all the machines I have used for making runs. 

2. Setup for gfortran is always the slowest for this application. 

3. gfortran does very well on the compute part of the runs.  A reduction in the runtime
of gfortran of 4 per cent would equal that for ifort!  I think I have used the the options
for ifort that are near optimum but I have limited experience on that compiler.  I suspect
that more experience might lead to a reduction in the setup time.  There appears to be 
some options for changing buffer allocation but I have not had the time to figure out
how that is switched on. 

4. The Lahey compiler is the fastest on the setup but is the slowest in compute.  Of course,
it is some years old and has no options beyond those that applied to the Pentium 4!  

Comments:

1. I am pleased to see efforts to reduce  floating point input times.
The test run used here is shorter than usual.  In longer simulation
runs, gfortran's compute advantage can sometimes make up for its I/O disadvantage,
but just barely.

2. If gfortran can reduce its read time to half of the above total, it will come
out, for this application at least, as having a better total time than the 
other three compilers.  

3. I'm not sure why Lahey is so fast on I/O.  It does have some user controllable setting
for buffer sizes, and I have used twice the default here.  However, testing with the default
shows only minor changes in times.  Another observation with the Lahey compiler: If
similar runs are made close together, the setup time drops significantly on the second 
and subsequent runs.  Therefore, for each of the above runs, I only took times after
an initial run was made without using its time results.  In all other compilers, the initial
run made no difference in the setup time.  Lahey is using or accessing some sort of 
cache that "remembers" something about the most recent inputs. 

4. I hope to do some tests with the 4.4 branch of the compiler to see what changes some
recent patches have made on the times shown here.  That may take a while-work load is
heavy right now--no downturn in my business:)

Finally, keep up the good work.  Coming within a few per cent of Intel, who should know
how to compile code for their CPU's, shows that the core computation part of gfortran 
is doing nicely, at least for my main application. 

                                     Delbert