bglenden@mandrill.cv.nrao.edu (Brian Glendenning) (12/07/90)
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@nrao.edu bglenden@nrao.bitnet (804) 296-0286