Subject: Re: CCL:FORTRAN versus C

From: [email-masked] (Scott Presnell)
Date: Thu, 10 Feb 1994 08:56:58 -0800

Moshe Olshansky writes:

>Personally I always preferred Fortran, but not because of it's performance.
>Here in Haifa we have a group working on improving the compilers for RS6000
>(both Fortran and C),  so I asked them about this issue.  Their response was
>that if one tries hard and writes a C program in a very special (machine
>dependent) manner,  it may perform quite well.  However, for programs
>written in a more or less standard language Fortran should indeed have
>a better performance than C,  and this is due not to the compiler but
>to the languages themselves.  Therefore,  it is very likely that Fortran
>will maintain a performance advantage over C for a long time.

(I wasn't going to jump into this, but...)

Even when spoken from a compiler group, I really don't see how this is
possible.  I don't write compilers, but most compilers for Fortran and C
I'm familiar with generate assembler code (virtual or not) from their
backend, independent of the language that enters on the frontend.  Hence
these high level languages are funneled through a common representation.  I
grant you that compiler technology may be at different levels of
development for different languages, but it seems to me that in the end,
you are limited by:

	A) The ability of the compilers to translate and optimize the high
level language into assembler.

	B) The constraints of the assembler available for the processor
under question.

There are indeed differences between Fortran and C specs (such as call by
reference vs. call by value), but I'm not aware of differences that would
allow for "better performance" given the above constraints...  Can you give
us some more detail on what your compiler friends are referring to?

	- Scott Presnell ([email-masked])

---

From: "G. Ravishanker" <[email-masked]>
Date: Thu, 10 Feb 1994 13:55:51 -0500

Hi

I could not resist throwing my two cents. We have several instances where
the MD code that we use, called WESDYN, has been subjected to the Fortran
vs C issue. That is, the non-bonded interaction routines have been written
in both languages and the wall-clock and CPU times were compared. It has
always turned out that Fortran beats C on several hardware
platforms. However, as many people have pointed out, the comparison has
several if's and but's. If one spends an awful lot of time tweaking the
C-code to optimize it, rather than simply running f2c type of conversion
programs, it is likely that the C version can be made to perform better.

The view we take is simple:

	1. The number-crunching portion of the program works faster in
Fortran for us, so stick with it. It is because we understand how to make
things perform better under Fortran from our prior experience. It is also
not hard to write Fortran '77 programs that are readable and structured
(not as structured as some hard-core computer scientists may like),
properly indented and all that. (emacs19 is an excellent tool for
this... Oh Oh, now I created a monster-- Which is the better editor vi or
emacs?)

	2. The code development in some ways is driven by who is your
user.  I cannot expect to develop a C program and give it to the group if
most of them are Fortran-wise.

	3. Front-ends, such as windows for inputting the data, or display
outputs are easily and elegantly programmed in C++ and most of the "number
crunchers" are simply not interested in getting involved at that level of
programming. So, do that portion of code in the most convenient language of
choice. 

Ravi

****************************************************************************
* Ganesan Ravishanker			Ph: (203) 344-8544 Ext. 3110       *
* Coordinator of Scientific Computing,  Fax:(203) 344-7960                 *
* Adjunct Associate Professor(Dept. of Chem.)                              *
* Wesleyan University               e-mail:[email-masked]  *
* Middletown, CT 06457.                                                    *
****************************************************************************