Path: utzoo!attcan!uunet!mailrus!iuvax!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.misc
Subject: Re: Fortran (or anything else) is efficient?
Message-ID: <2314@l.cc.purdue.edu>
Date: 4 Jul 90 20:38:04 GMT
References: <9595@brazos.Rice.edu> <138349@sun.Eng.Sun.COM> <2306@l.cc.purdue.edu> <1990Jul4.173753.23361@portia.Stanford.EDU>
Organization: Purdue University Statistics Department
Lines: 60

In article <1990Jul4.173753.23361@portia.Stanford.EDU>, dhinds@portia.Stanford.EDU (David Hinds) writes:
> 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.

My statement stands.  What I was really getting at is that I cannot even tell
the compiler what I want to do in any sensible manner much of the time, and,
in addition, the optimization is usually far worse than a human with reasonable
understanding will do, if you let the human do things the compiler does not
know about.  Now some of the newer machines have removed those useful
instructions.  

			 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 have not looked much at parallel processors, but I have at vector processors.
There are many algorithms which do not parallelize worth a darn.  Some of 
these can sometimes be vectorized, but a single instruction can make a big
difference.  But I do not know how to write those things in Fortran (or any
other HLL) in such a way that any compiler I have seen can recognize what is
wanted.  Some of these situations are quite simple--the gurus just have not
thought of them.

>     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.

A graduate student working for me who had never programmed for a vector
computer was amazed at how little of the vectorizable code in a rather
simple algorithm was not vectorized.  Of course, that could have been
predicted, as there were certain parts of the code which could only be
vectorized if the machine were understood, and without these, some of
the rest did not look right.  BTW, much of that could not have been
vectorized on the CRAY 1, but could with great difficulty on the X-MP.

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)