Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!timbuk!juniper04!tbc
From: tbc@juniper04.cray.com (Tom Craig)
Newsgroups: comp.lang.fortran
Subject: Re: Missing the whole point (the Fortran vs. C debate)
Summary: not really ^
Message-ID: <185951.1857@timbuk.cray.com>
Date: 4 Dec 90 01:16:16 GMT
References: <28548@usc>
Sender: tbc@crayamid.cray.com
Organization: Cray Research, Inc., Eagan, MN
Lines: 31

In article <28548@usc> ajayshah@almaak.usc.edu (Ajay Shah) writes:
>
 [Valid points on the relative importance of programmer productivity
  deleted]
>
>Face it: optimisers can give you 2x gains *at best*.  Hardly the
>kind of thing to be basing an entire computational strategy on.

Hmmm, I have to differ here. On multiple-cpu vector architectures, 
the difference between best case (vector code running on multiple cpus) 
and the worst case (single threaded scalar code) is more like 100x. There 
are still many very interesting problems that can be practically modeled on a 
super-computer ONLY by squeezing every ounce of speed out of the computer.
When the hardware speeds up, there will be new interesting problems that
require that primary attention be given to performance. Scientific 
programmers ALWAYS want 10% more speed that the system can deliver!
 
 [Valid tirade against bad code deleted in the interest of bandwidth]

This argument doesn't fly either. You can write good code or bad code
in any language. At this point, (at least on Crays), if you want to
get the best performance out of a large numeric code, you either have
to use FORTRAN or restrict yourself to a FORTRAN-like subset of C, in
which case, you might as well use FORTRAN. On second thought, if you're
more comfortable with C, use it with a keen eye to vetorization and
parallelization. It`s just easier to avoid loops that don't vectorize
with FORTRAN.

Regards,
--
   Tom Craig     tbc@cray.com     Insert standard disclaimers here...


Brought to you by Super Global Mega Corp .com