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-0286john@ghostwheel.unm.edu (John Prentice) (12/07/90)
In article <BGLENDEN.90Dec6151150@mandrill.cv.nrao.edu> 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
mwm@VACATION.VENARI.CS.CMU.EDU (Mark Maimone) (12/08/90)
It turns out that the problem Brian had with a "real" identifier
was exactly that. "REAL REAL" got translated into "real real;"
(where real is a type defined in f2c.h), which the compiler then rejected.
A simple fix, which will be incorporated in the next f2c release,
is to add the names of all types that are typedef'ed in f2c.h to the
list of c_keywords in f2c (names.c, "c_keywords" definition). This will
correct the above example to: "real real_;", which the C compiler will
accept. We included most keywords here but forgot about the standard
types. Sigh....
Thanks for the bug report!
----------------------------------------------------------------------
Mark Maimone phone: (412) 268 - 7698
Carnegie Mellon Computer Science email: mwm@cs.cmu.edu
grad student, vocal jazz and PDQ Bach enthusiastflint@gistdev.gist.com (Flint Pellett) (12/11/90)
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. I didn't catch the previous discussion, but having used f2c, I have a couple of comments on it. I tried mailing these to the creators but couldn't get the mail thru. While I realize the goal of f2c is merely to output "something that runs", there are some problems in trying to take the output and do debugging in the C code that are possibly easily correctable. (If there is no intention at all to let someone work with the resulting C code at all, you might as well strip the comments out altogether, or provide an option to do that.) 1. f2c munges over static data declarations pretty bad. In particular, it does two things that I dislike: the first is that it moves all the actual data declarations up to the top of the resulting C file, while leaving all the comments that explain what each piece of data is for unmoved. So if you had 50 lines of data intermingled with 50 lines of comments explaining what it was for, you end up with 50 lines of data followed by 50 lines of comments and a hard time figuring out what comment refers to what data. The second objectionable thing: it turns all the data into decimal. If the data was originally written in Hex, it was probably written in hex for a reason, and it ought to be written back out in hex notation. I see no real reason why this type of stuff should be done, since the FORTRAN DATA statements are translatable linearly into C declarations without any need to reorder anything. 2. f2c removes parenthesis and changes where lines break in -if-s. (Again, there does not appear to be any good reason for this.) If the code started out looking like this: if ( (thing1 .eq. thing2) .or. + (thing3 .ne. const) ) It ought to come out as: if ( (thing1 == thing2) || (thing3 != const) ) Instead of what f2c produces now as often as not, which is: if ( thing1 == thing2 || thing3 != const ) 3. One other suggestion: It would be a massive boon to the usability of this software as a translator that intended to be used to produce C that was good enough that the original could be discarded if it allowed you to build a variable name translation table, and then changed variable names for you, based on lines in a file that looked something like this: lcstok long_char_string_token -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com