Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!news.cs.indiana.edu!ariel.unm.edu!ghostwheel.unm.edu!john From: john@ghostwheel.unm.edu (John Prentice) Newsgroups: comp.lang.fortran Subject: Re: f2c experience Message-ID: <1990Dec7.055000.29126@ariel.unm.edu> Date: 7 Dec 90 05:50:00 GMT References: Sender: news@ariel.unm.edu (USENET News System) Organization: University of New Mexico Math Dept., Albuquerque, NM Lines: 93 In article bglenden@mandrill.cv.nrao.edu (Brian Glendenning) writes: > >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