🚀 go-pugleaf

In article <2306@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>> >    Geez, is this a cheap shot, or what?  FORTRAN has its weaknesses,
>> >but inefficiency is not one of them.  I know of no other language that
>> >can be as effectively optimized.  
>
>That a language can be optimized (and I do not think that Fortran has ever
>been effectively optimized) says nothing about the efficiency of the language.
>There are important constructs, such as pointers, which have been missing from
>Fortran from day 1.

   What do you mean by "effectively optimized"?  I would guess that for your
statement to be valid, you mean that NO language has ever been effectively
optimized.  This may be true, but is beside the point.  As a trivial example,
our MIPS Fortran compiler uses the same global optimizer as all other MIPS
compilers, so Fortran is certainly at least as well optimized as any other
language on the machine.  The optimizer does take some advantage of language
specific features, though, so Fortran is probably somewhat better-optimized.
We also got a tool with the compiler that (almost) automatically determines
data dependencies, unrolls loops, and parallelizes our Fortran code.  Gee,
there doesn't seem to be (maybe can't be?) a tool like that for our C
compiler.  Only the Fortran compiler has a "-mp" flag...
    I think it is fair to say that mature mainframe Fortran compilers are
"effectively optimizing".  IBM's compilers are supposed to be quite good,
and difficult to beat with hand-coded assembler.  And Fortran is still the
language of choice for vector architectures, I think.  I agree that in
many ways, Fortran stinks, but for some tasks, it is still the best tool
available.  With a preprocessor so I never need to type a line number or
a CONTINUE statement, I can grudgingly bear it.

 -David Hinds
  dhinds@Popserver.stanford.edu