NOT Educating FORTRAN programmers to use C

[Jim Giles]

>From article <21730 at mimsy.umd.edu>, by chris at mimsy.umd.edu (Chris Torek):
> In article <14186 at lambda.UUCP> jlg at lambda.UUCP (Jim Giles) writes:
>>C is inherently slower [than FORTRAN] because extensive pointer use
>>inhibits optimizations.
> 
> Like all sweeping statements, this one (actually `these two') is
> (are) false.
> 
> There is a large class of machines on which pointers are as efficient
> as, or or more efficient than, arrays, [...]

Like many C supporters, Chris Torek tends to confuse wishful thinking
with facts.  The above "large class of machines" is actually increasingly
narrow.  Even cheap home computers are starting to be built with pipelining
CPUs in them.  Many intermediate range machines are becoming available
which are vector archetectures.

Even on the class of machines that Chris Torek is talking about, the
use of pointers is not "as efficient as, or or more efficient than, arrays".
The weakness of this claim is that, on the machines he is discussing,
arrays and pointer manipulation are semantically _identical_!  So the
best you can hope for, given equal quality implementation, is exactly
equal performance.

> [...]
> There is a large class of problems, too, which cannot make use of
> vector instructions.  Only for those problems that can, on those machines
> that can, is this a significant loss.

There is an even larger class of problems which can be, at least,
partially vectorized.  And nearly all problems can benefit from
code movement optimizations on pipelined machines (at least, if
pointer usage hasn't inhibited such optimizations).

> [...]
> (This of course is what `noalias' was all about.)

Exactly right.  But the last I heard, 'noalias' had been deleted from
the proposed standard.  I've not seen any C compilers with it yet.

Even if 'noalias' were to become part of the standard, this would still
only mean that Fortran programmers could not expect anything more than
equal performance from the massive expense of moving to C.  Hardly a
reason to switch.

J. Giles