[comp.lang.fortran] f2c experience

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

john@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 enthusiast

flint@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