C vs. FORTRAN

[Ross Wetmore]

In article <3136 at phoenix.Princeton.EDU> mjschmel at phoenix.Princeton.EDU (Michael J. Schmelzer) writes:
>Given that C produces assembly code very similar to the source
>code it came from, why should it be any slower than the object
>code generated by a FORTRAN compiler?
>
>What is missing from the equation here? I am currently writing
>programs in C and FORTRAN and thus have some interest in the matter.
>Mike Schmelzer mjschmel at phoenix!princeton.edu

  Part of the problem is that the presence or absence of certain
constructs in the high level language predisposes the programmer
towards a particular algorithm or coding style. Thus an algorithm
written in simple Fortran might be quite radically different than
one written in simple C.

  In C exponentiation is not an operator, but rather a function.
I have seen C programs where a for-loop has been used to avoid
doing a pow() function call or because simple integer exponentiation 
doesn't really exist. A Fortran programmer doesn't really think
and just uses '**' which usually just gets translated into an
appropriate function call by the compiler. The point is that the 
C programmer may produce a radically different program because of 
the different thought process required. The reverse happens when a
C concept like pointers is missing from the language.

  What is needed is a way to preprocess code or add compiler
extensions so that the expression of simple concepts can be done 
with simple high-level code and the implementation is left to the 
compiler. Even better is if the extensions can be added dynamically
by the programmer for his particular application, rather than 
rewriting the code to use a compiler which has the maximum overlap 
with his favorite set.

  For example a scientific application package might be a trivial
program in a language where a data types 'vector' and 'matrix'
existed with standard operators '+-*/' doing the appropriate thing.
Moreover if a new super-hardware device comes along to replace the
functions that presumably get called to do the actual work, then
the user need do very little more than recompile with a new compiler
switch or function library. This is far more preferable and less
time consuming than global changes to explicit programmer implement-
ation of the same functionality.

  Rather than converting Fortran to C, or Cobol, or PL/1, it might be
more worthwhile to look at some of the more flexible languages such
as C++ or ADA or their future incarnations. Hopefully, the relearning
cycle and upgrade path for these will be somewhat less steep after
the initial conversion, as the basic compiler is less liable to change,
but rather different packages of 'includes' will come along to provide
extensions and new features.

Ross W. Wetmore                 | rwwetmore at water.NetNorth
University of Waterloo          | rwwetmore at math.Uwaterloo.ca
Waterloo, Ontario N2L 3G1       | {uunet, ubc-vision, utcsri}
(519) 885-1211 ext 3491         |   !watmath!rwwetmore