Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!noao!mcdsun!sunburn!gtx!edge!doug
From: doug@edge.UUCP (Doug Pardee)
Newsgroups: comp.misc
Subject: Re: Better compilers (1.3 wish)
Message-ID: <900@edge.UUCP>
Date: Tue, 11-Aug-87 17:41:56 EDT
Article-I.D.: edge.900
Posted: Tue Aug 11 17:41:56 1987
Date-Received: Sun, 16-Aug-87 06:44:49 EDT
References: <1428@sputnik.COM>
Organization: Edge Computer Corporation, Scottsdale, AZ
Lines: 75

> The best optimizing compilers are now better than the best
> human-coded assembly language for program more than a few hundred lines
> long.

I'm afraid this is a statement which has nothing to back it up.  It's easy
to say things like this, but it is like the current fad of rating computers
via a single figure like MIPS.  There is no one "best" language and no one
"best" compiler, not even if we limit ourselves to one specific area of
appication.  The choice of programming language is always one of compromise.

Also, I'm getting weary of hearing tales of how "there exists somewhere" a
fancy-shmancy compiler that is better than assembler, and therefore we
should code in that compiler's language even though that compiler isn't
available to us and we're stuck with using some terribly inefficient
compiler like PCC.  "Optimization by association", perhaps?
[To be fair, the posting that I'm quoting made no such comment.]

> the best compilers are
> better than humans now because they do things to the code that are
> considered bad style for a human-maintainable assembler source, like reusing
> the same storage location for different variables, storing the same quantity
> in different locations/registers during the program run, moving code around,

True, but even if you happen to have such a compiler available to you, those
optimizations are peanuts compared with what a good assembly implementation
can often achieve.  Sometimes an application is not a perfect fit for any
available high level language.  The result is that the code is "made to fit"
some available language, and that usually sends efficiency down the drain.

An example might make it clearer:  suppose you're programming an application
which does a lot of string processing, and the languages you have available
are C and FORTRAN.  Neither C nor FORTRAN provide any way for you to access
whatever string-processing instructions are built into your computer; you
end up either manhandling each byte or calling numerous subroutines.

> By the way, it is hard to optimize c very highly because of things like
> pointers and lax type checking.  In principle, the best-possible object code
> from a pascal program will be tighter than the best-possible object code
> from a c program doing the same thing.  The tricks c uses to permit a
> relatively crummy compiler to produce decent code hobble a really good
> compiler.

Right on!  But this is also one of the significant reasons for the higher
efficiency of assembly code: the assembly programmer knows precisely (it
says here) what the aliasing effects of pointer usage will be, which is
something that he would have to somehow communicate to a compiler.

> [story of bad sort algorithm recoded in assembler doubling the speed, but
> being beaten another tenfold by a good sort algorithm coded in assembler].
> So what's the big deal about assembler?  Algorithms and tuning is
> where it's at.

I absolutely agree, algorithms are critically important.  A mediocre
implementation of a good algorithm is almost always going to beat a good
implementation of a mediocre algorithm.

But seriously, does it happen very often that time pressures force you to
being implementation while you're still turning up even better algorithms?
I've had it happen a couple of times, but usually I reach a limit, where
I've found the most effective algorithm that I'm likely to find.  Bad
algorithm choices stem from programmer laziness, not time shortage.

Besides, it just isn't true that assembly language programming takes a
lot longer than high level language programming.  Sure, for someone who
doesn't *know* assembler it does :-)   And for those applications which are
a "natural" for an available high-level language.  But for many applications
it's just as quick or even quicker to code in assembly language.

If the only tool you know how to use is a hammer, everything looks like a
nail.  But it takes a lot of hammer bashing to drive a screw into a piece of
wood.  Getting a bigger and more effective hammer helps, but it still isn't
as quick (and clean) as using a screwdriver.   [Which isn't to say you
should use a screwdriver to pound nails...]
-- 
Doug Pardee, Edge Computer Corp; ihnp4!mot!edge!doug, seismo!ism780c!edge!doug