[comp.lang.fortran] C/FORTRAN holywar

danny@itm.uucp (Danny Cox) (12/07/90)

I'm posting this for Glen Clark.  Please use the return path
at the end of this article to reply to.... DSC.


I am puzzled by the ongoing C .vs. FORTRAN holywar. The recent
blizzard of exchanges left my news mailbox fuller than any other
time in recent memory. I am willing to cede the fields of most
business programming to C, but I fail to follow the arguments of
those who contend C offers anything to the numerical analysis/
scientific communities that they can't get elsewhere.

We have continued using FORTRAN in our office (to this point)
because of a *decided* advantage is floating point speed. I don't
mean 10 or 15%. I mean that algorithms coded in FORTRAN ran 3X,
4X and even sometime 10X faster than equivalent C code run on the
same machine. This was primarily due to the heavy floating-point 
nature of our work, but what can you expect when many C compilers 
thought it would be a needless luxury to bother to include a
library that included calls to the 68881? (Admittedly, these
tests are a few years old). 

I don't take this as an indication that FORTRAN is 
intrinsically better (whatever that means) than C, but simply 
that FORTRAN compiler designers have been more concerned about 
floating point performance than the C_faithful who were so taken
with the cleverness of what they had created, that they tilted
their chairs back, stared at the wall, and mused "Wow man. 
Recursion. What a concept!", and left their floating-point
libraries static (and useless) from 1983 to 1989.

I have no religious attachement to any language. Our CPU hardware 
is a major part of the expense of running our business. If someone 
would show me where we could double our throughput by programming
in COBOL, I would have someone begin recoding our man-years, of 
written_in_house programs in the morning.
 
I believe Press et al said it better than I could hope to in
NUMERICAL RECIPIES, so I will simply borrow a line or two:

	"In traditional C, float variables are automatically
	converted to double precision. ... The justification
	is, "well there's nothing wrong with a little bit of
	extra precision". ... One does not need much experience
	in scientific computing to recognize that the implicit 
	conversion rules are, in fact, sheer madness! ... They
	make it impossible to write efficient numerical 
	programs. One of the cultural barriers that separates 
	computer scientists from "regular" scientists and 
	engineers is a differing point of view on whether
	a 30% or 50% loss of speed is worth caring about. ...
	The practical scientist is trying to solve tomorrows
	problems with yesterdays computer; the computer 
	scientist, we think, often has it the other way around."

Apparently someone listened to Press, because  this condition has 
changed within the last year. For the first time since we began
comparative benchmarking of hardware/software combinations 10 years 
ago, C's floating-point performance is at parity on *some* platforms.
For our in-house benchmark, we found that both the SPARC 1+ and the 
RS6000 have C floating point speed that is equivalent (within 1 or 
2%) to the FORTRAN. But notice I said 'parity', not advantage.

Now my question: 

	What does C do for me in the world of numerical
	analysis/scientific programming that FORTRAN won't? 

If the advantage isn't speed of EXECUTION, then it must be speed 
of code DEVELOPMENT (i.e. flexibility of the language) or memory
conservation. (Execution time, development time, and efficient
hardware resource utilization. What else is there?) If I was
writing a relational database manager, or rewriting American 
Airline's SABRE reservation system, I'd pick C in a New York
minute as the only rational tool. But if I don't need to code a
B-tree search, what can C give me I don't already have? The only
comment I have seen that even began to address any tangible 
utility advantage (as opposed to religious conviction) was 
Pierre Asselin's recent comment on building "unstructured meshes".

	[I also agree with John Phelan's premise that the future
of scientific computing is massive parallelism, therefore the
focus of the FORTRAN-9X standard should be more on meeting that
meritorious challenge, and less on adding more C-like features.]

	I don't pose the above question to be a wise guy. If 
someone has a valid answer, I'd really love to know. (Maybe 
I'm telling the world how little I know) But please, if you 
have an answer, put it in a form relating to what you can DO 
with it, not how NEAT it is:

   (i.e. having the form:

	"C has a rich library of intrinsic functions which
	 are pipelined to make more efficient use of the
	 floating point hardware. The polar-to-rectangular 
	 conversion function RECT(R,THETA,X,Y) provides for
	 the simultaneous performance of the

		X=R*COS(THETA) and Y=R*SIN(THETA)

         tasks, thereby resolving the polar-form vector into
	 its cartesian components in half the time. Therefore,
	 many vector-intensive programs will execute in
	 significantly less time."

   not:

	"C allows the creation of flat arrays of the data
	 type foobar, allowing them to be cross-connected
	 to the warp-drive engines, and isn't that cosmic?"

     )

I learned FORTRAN-66 on a CDC 6600, made an IBM 370 learn to 
hate me, and spent almost as much time using a DEC-10 in 
single-user mode as I spent in the Army. (Even took a side-trip 
to model the RF environment in downtown Chicago in ALGOL on a 
Burroughs 5500.) But excepting a few "close_to_the_hardware" C 
functions that would have been helpful when writing our own 
plotter drivers, I have yet to find something that I needed to 
do that couldn't be done straightaway in FORTRAN. 

Even Microsoft F-80 (FORTRAN for the 8080) under CP/M (heaven 
help us) allowed one (with clever use of the .AND. operator) to 
go grab the status byte off the UART, mask off what you want, and 
make your own flow control. 

So what's the BIG deal with C?


	Glen Clark
	Glen Clark & Associates
	Consulting Engineers
	Alpharetta, GA

	gatech!dscatl!opto!glen

	(404) 740-0178

staff@cadlab.sublink.ORG (Alex Martelli) (12/09/90)

Just a wee bit of input - I abhor holy wars as much as you do, and since
I daily program in both Fortran and C, have no stake in it either way.
I hope, however, that it may be useful to you and others if I present
some technical considerations and observations that I have performed
during my work here in CAD.LAB.  I wish to emphasize that, although
this matter IS part of my daily job, the thoughts I want to share with
you are MY OWN, PERSONAL ideas, and must NOT be taken in any way as
"opinions" or "positions" of CAD.LAB S.p.A..

My observations are all based on WORKSTATION-class machines, OS/2, VMS,
and, mostly, Unix boxes.  Our programs have rather precisely delimited
sets of routines which perform heavy numerical computation (on the
usual 20% of the code, 80% of the crunching, kind of scale); I *USED*
to think that it would be CRAZY to even THINK about recoding these in
anything but Fortran, until I started doing some benchmarks a few
months ago with f2c.  At the time I posted some numbers to this very
group, astonished as I was - going through f2c made performance BETTER
on some platforms, notably Sun ones!  I had some correspondence after
that, but nothing came of it - I did not hear anything more from those
I had sent my code to, etc.  I'll have to redo the benchmarks on the
Sparcompiler some day.  A more usual result was reasonable degradation,
between 5 and 15 per cent.  These were double-precision computations
anyway, but then this IS most of what we have to do; if we had heavy
single-precision requirements, on some boxes forcing double precision
would be a heavy hit, on Sun we could use the nonstandard -fsingle
switch on cc, and on others such as IBM RS6000 one would hardly notice
the single vs double precision difference; a bit difficult to get
reasonably general conclusions from such a varied picture.

For anything BUT straight numerics, C shows incredible performance wins
on our hardware.  I/O, for example, is FAR simpler in C, and better
adapted to what the underlying OS/2 or Unix system provides - the
Fortran compiler seems to have HEAVY overhead - to cut it short, a
checkpoint to disk is quite likely to take TWICE as long from Fortran
as from C!!!  I do NOT think this is in any way inevitable; I believe
a Fortran runtime library WILL always have more overhead, but on the
*few percents* level, definitely NOT 100% as I have observed; thus I
must conclude that the Fortran compilers/libraries we use on these small
machines are simply BADLY IMPLEMENTED, at least for I/O.  Manipulation
of characters is more of the same; SOME overhead is implicit in the
Fortran standard (implicit fill-with-blanks, implicit runtime checks
for boundaries, etc), but in practice C measures FAR better than this
little things would imply - or should I say, Fortran (the compilers
available to us) measures far worse.  

Taking all of this into account, our strategy is to move our LOW-level
code more and more to C - comes out more portable (no more wondering
what type is needed in an INQUIRE(), what unit of measures, bytes or
longwords, must be specified in the RECL of an OPEN(), etc), more
maintainable (thanks to better structure, layout, mandatory variable
declaration, etc, which we could not get PORTABLY in fortran across
more than a dozen platforms), and with measurably better performance.
It's also easier to find people coming out of universities with good
command of C than of Fortran, nowadays; a minor point, but this has to
be taken into account too.  This is for the kind of people we want
for low-level, close-to-the-system work: graphics, algorithms, I/O,
abstract datatypes, all sorts of "computer science" stuff which, of
necessity, goes into a well-rounded software system.
At *higher* levels Fortran stays - no real reason to redo hundreds of
thousands of lines of code, unless gradually - also the people who
work on the more application-oriented portions tend to be mechanical
and civil engineers, and THOSE are still easier to find with some 
knowledge of Fortran than of C - again a minor point, but not fully
to be ignored!

I have ignored so far the ability, with C, to express naturally and
effectively more complex structures, through pointers.  I know most
Fortran users will scoff at this, but take care: unless you are only
working with DENSE arrays, you are already losing the "simplicity"
of straight Fortran, and should benchmarks some of your application's
kernels in C.  Sparse matrices are better represented through arrays
of pointers than array of indices into other arrays; an array of
structures will have better locality (for caches and paging) than
the traditional "separate, but 'parallel' arrays" one would use in
Fortran; and whenever you have to "swap data around", you might be
better off swapping pointers to them instead (again, swapping
indices adds a level of indirectness, which makes performance worse).

These apply to both high- and low- level components of applications,
so why am I not "pushing" C over Fortran even more in our company?
First, I'm NOT talking about orders of magnitudes improvement, and
we already have a LOT of Fortran code out there; recoding for 10 or
20 percent improvement, when in any workstation family more than that
is routinely offered every YEAR by manufacturer, is a rather marginal
investment; C is not some "silver bullet" that will make your data
structure and algorithms better by itself, you have to back it up
with study and work to get THIS class of improvements!  So I'd rather
have our engineers think about the other engineers that will be using
our codes, rather than, at least in part, becoming computer scientists.
Besides, I believe even more of this sort of improvements, and others,
will be available shortly from a swith to Object-Oriented software
engineering techniques and languages; so I'd rather invest in THAT in
a short while.

-- 
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia
Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; 
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).

khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (12/18/90)

>on our hardware.  I/O, for example, is FAR simpler in C, and better

This is purely an artifact of the IO library, not the Fortran model. 
--
----------------------------------------------------------------
Keith H. Bierman    kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33			 | (415 336 2648)   
    Mountain View, CA 94043