f2c experience

[Brian Glendenning]

I'm the fellow who started the most recent reincarnation of the
Fortran vs C discussion - I'm afraid that discussion digressed more
than I wanted it to and I'm sorry about that.

Anyway, I decided to run our package through f2c. Here's a little note
I wrote up about my experience.

Brian
===========================================================================

I have compiled the subset of AIPS (Astronomical Image Processing
System) required to run our benchmakrking/validation suite with the
Fortran-to-C converter (f2c) from AT&T (this code is publicly
redistributable).

The compiled subset (about 7% by number of programs) consisted of
165,000 lines of Fortran and 6700 lines of C (to handle the OS
interface, signals, etc). I ran it on a Sun/4 110
(mandrill.cv.nrao.edu) running SunOS 4.1 and the 15OCT90 version of
AIPS (256kword = 1MB "core" size).

The only changes required to get AIPS to compile were to change some
variable names from "REAL" to something else in about a dozen
routines. Although legal f77, this is probably a bad practice in any
event. Since AIPS has been known to break many compilers in the past I
think this speaks highly of the quality of f2c.

The bulk of the code was compiled with no optimization, while the most
numerically intensive portions of the code (the so-called Q routines)
were compiled with Sun's cc -fsingle -O4.  For the Fortran comparison
the compilation was the same aside from -fsingle which is
meaningless for Fortran.

The resulting f2c code passed the verification suite with flying
colours. This surprised me a bit since I thought that we might run
into parentheses grouping problems since Sun cc is a K&R compiler and
I didn't specify the flags to force f2c to follow Fortran evaluation.

		    Small (256^2) DDT f2c Results

Task     What                           Correct bits RMS       Correct bits worst pixel
UVMAP    gridded FFT imaging            I=19, B=17*            I=10, B=10
APCLN    "clean" deconvolution          21                     14
APRES    deconvolution residuals        22                     17
MXMAP    gridded FFT imaging            I=19, B=20             I=14,B=14
MXCLN    "clean" deconvolution          18                     14
VTESS    Maximum entropy deconvolution  27                     20
                                        *I,B = Image, Beam

UVSRT    Disk Sort of ungridded data    Pass
ASCAL    Self calibration of "closure"  Pass
         errors

These numbers are typical of what we find when bringing up AIPS on any
new system.

The timings were very interesting (CPU times only - although the system
was fairly unloaded it wasn't completely so):

Task    f2c(s)    f77(s)     f2c/f77
UVSRT   12        10         1.20
UVMAP   30        28         1.07
APCLN   408       350        1.17
APRES   20        17         1.18
ASCAL   285       176        1.62
MXMAP   48        40         1.20
MXCLN   688       463        1.49
VTESS   119       90         1.32
TOTAL   1610      1174       1.37

I believe that ASCAL's speed may be ascribable to the fact that with
the options I have chosen sin/cos are probably not inlined (this is
correctable).

More interesting is why MXCLN and APCLN, which do fundamentally the
same thing, run at different rates under f2c. I have no answer to this
now.

What can we conclude from this? Well, the obvious thing is that it
works and we can make AIPS run on machines without Fortran compilers.
Next, I believe that the above performance numbers could be increased
with modest amounts of effort, even with changes as trivial as
compiler command line options. If this is true it may have important
consequences in how we direct "new AIPS." I think we should consider
pursuing this experiment on more interesting machines such as the
Convex and the IBM workstation (or even with gcc on Suns).

Brian Glendenning, 12/6/90.
--
       Brian Glendenning - National Radio Astronomy Observatory
bglenden at nrao.edu          bglenden at nrao.bitnet          (804) 296-0286