Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!borland.com!sjc
From: sjc@borland.com (Steve Correll)
Newsgroups: comp.lang.fortran
Subject: Re: FORTRAN vs. "PC languages"
Message-ID: <1991May30.181809.25603@borland.com>
Date: 30 May 91 18:18:09 GMT
References: <31746@rouge.usl.edu>
Distribution: usa
Organization: Borland International
Lines: 71

Prof. Lafleur asks an interesting question: essentially, "If you had to write a
numerical application entirely from scratch, would you use Fortran or C++?"

I wouldn't use Pascal, C, or Modula-2, because each has at least one of these
defects:

 1. Can't declare a true multidimensional array with arbitrary lower bounds.

 2. Can't reshape an array by passing it as an actual argument, or design a
  single function to operate automatically on arrays of varying shape.

 3. Can't use intrinsic functions and operators on doubleprecision and complex
  data.

 4. Can't control the precision and order of evaluation of arithmetic
   expressions.

The good news? C++ can do all of these. Examples in Stroustrup's book provide a
starting point for (1) and (2); as noted, Borland C++ provides a library for
(3) (actually, it's for doublecomplex, but complex is an easy extension).

Fortran remains much more convenient with regard to (4). Whereas Fortran says
"parentheses are sacrosanct", C++ permits the compiler to use arithmetic
identities which create or destroy parentheses, so the user may need to break
an expression into multiple assignment statements to prevent reordering.

Fortran 90 has raised the goalposts somewhat by adding dynamic allocation,
array sectioning, and intrinsic functions and operators on arrays, but these
are all clearly possible with C++: somebody just has to spend time writing
class libraries to implement them.

So what's the bad news?

The C++ compiler has a tougher time generating efficient code, because it knows
less about the program. For example, confront a hypothetical Fortran 90 compiler
with a statically indexed array copy:

	X(1:10) = X(11:20) + X(21:30)

It can observe at compilation time that the source and target are disjoint and
emit special-case code that avoids using an intermediate temporary array. The
C++ compiler sees a bunch of operators overloaded with library functions which
were written to handle the general case, where copying is required. If the
author of the functions was careful, s/he tests the source and target for
disjoint-ness and branches to special-case code which avoids the temporary--but
that test occurs at execution time, every time you invoke the operation.

(Other examples involving dynamically indexed arrays are equally problematical
for both compilers, of course.)

In time, I expect the best C++ implementations will inline the function calls,
analyze the dependencies, eliminate the test, discard the unreachable code, and
thus generate the same code as our hypothetical Fortran 90 compiler does in the
special case (and better code in the general case, unless the Fortran 90
compiler adopts similar optimizations).

But the C++ implementor must solve a bunch of general problems in optimization
(a lot of work, at the end of which everything runs faster) whereas the
Fortran 90 implementor can use heuristics to optimize specific common cases
(only the common cases improve, but you can deliver sooner).

A rash prediction: early Fortran 90 compilers will be so lousy that the best
current C++ implementations with carefully written class libraries would beat
them at execution time. Later Fortran 90 compilers will step ahead via
heuristics. Then C++ will catch up by implementing more sophisticated general
optimizations sooner (Fortran 90 compilers are handicapped by a late start, and
will spend a lot of time shaking out semantics-versus-optimizer bugs due to
their complicated source language). In the long run, if Fortran 90 is popular,
its compilers should come out ahead in performance both because some things
just aren't visible to C++ at compilation time, and because the Fortran
market values numerical performance more highly than the C++ market does.