Wanted: Ultra-fast fortran compiler for UNIX

Donn Seeley donn at utah-cs.UUCP
Thu Aug 1 17:46:08 AEST 1985


I wasn't going to get into this discussion, since my opinions on f77
are well known and (in part) unprintable, but I decided I ought to
contribute a few remarks on Mr. Freyburger's article...

	From: doug at escher.UUCP (Douglas J Freyburger)

	I'm sorry, but I have troubles giving credit to a compiler that
	is fully 30% slower than a competitors compiler for the same
	machine architecture in the same language.

I'm not sure where Mr. Freyburger comes from...  He doesn't seem to be
acquainted with bad software.  The 4.1 BSD f77 compiler was quite
capable of producing code that ran 2 or 3 times slower than code from
VMS Fortran.  The VMS compiler ran faster, too.  Bad code quality is
not uncommon in the industry, unfortunately, and VMS Fortran is a
shining example of how to do the job right.

Also, unless the numbers have changed since I last saw them, the
margin VMS Fortran has over 4.2 f77 on the LINPACK benchmark is not
as great as 30%; someone else has mentioned this as well.

	Does going from blind translation into assembler really cost
	30% more execution time?  I always thought that good
	optimization was less than that.

It depends on what kind of machine you're on, what kind of compiler
you've got, and how good you are at assembly programming.  When I
rewrite routines into assembler, I'm disappointed if I can't double
their speed; if I can't do that well, I rarely bother.  This applies
even to C routines.  The VAX has a number of peculiar instructions that
make assembly coding more useful, however...  (For example I recently
doubled the speed of Berkeley Mail by recoding fgets() and fputs() in
assembler.  A Fortran program which did direct I/O improved in speed by
a full order of magnitude when loaded with the 4.3 BSD fread()/fwrite().
Due to the peculiarities of the VAX architecture, writing these
routines in C would have been very machine-dependent at best and
impossible at worst.)

	Does the Berkeley compiler do no loop-invarient migration,
	common expression elimination or ANYTHING?

The Berkeley compiler does loop optimization, common subexpression
elimination, register allocation and a number of other optimizations.
As I said above, if you don't do these things, your difference from
the optimum can be 300% instead of 30%.

	It is true that DEC worked very hard optimizing its ForTran's
	output, but 30%?  ...

To say that 'DEC worked very hard' is a gross understatement.  Have you
priced their compiler?  The fact that their Fortran compiler costs
considerably more than an entire distribution from Berkeley should tell
you something...  And I will say right here that if your site does
nothing but number crunching with Fortran, your money is better spent
on the VMS Fortran compiler than on 4.3 BSD.  If you run Unix you must
have other reasons for doing so (and apparently many people do, or you
most likely wouldn't be reading this message).

Have any of you ever wondered what it takes to get someone to work on
free software?  Anybody who knows anything goes off to start their own
company...  Getting people to produce a fast math library for Unix on
the VAX is not unlike getting people to contribute to Harold Stassen's
campaign fund.  (And yes, I still consider the math library to be the
worst aspect of computing with f77.) Only a sucker would waste their
time writing free software for Unix when they could go private and cash
in.

Still a sucker,

Donn Seeley    University of Utah CS Dept    donn at utah-cs.arpa
40 46' 6"N 111 50' 34"W    (801) 581-5668    decvax!utah-cs!donn



More information about the Comp.unix mailing list