Benchmarks on reading floating point values

[Paul Richard Thomas]

Dear Delbert,

Thank you for the encouraging message.  Hopefully, the patches in the
pipeline will improve the set-up time.  The performance on the
execution phase is consistent with other comparisons (see
www.polyhedron.com, for example).  Apart from I/O, one of our biggest
performance shortcomings is associated with inlining of some
intrinsics.  We hope to have that licked in 4.5.

As a matter of curiosity, are you using your Aspire One in its Linux
or Windows manifestation?

Cheers

Paul

On Tue, Jan 6, 2009 at 7:47 AM, Delbert Franz <ddf@iqdotdt.com> wrote:
> 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
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy