Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!news.cs.indiana.edu!rutgers!gatech!itm!danny
Newsgroups: comp.lang.fortran
Subject: C/FORTRAN holywar
Message-ID: <1202902230@opto>
Date: 7 Dec 90 13:17:25 GMT
Sender: danny@itm.uucp (Danny Cox)
Organization: Glen Clark & Associates
Lines: 138

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