Xref: utzoo comp.arch:17001 comp.lang.misc:5117
Path: utzoo!attcan!uunet!bu.edu!purdue!mentor.cc.purdue.edu!noose.ecn.purdue.edu!dynamo.ecn.purdue.edu!hankd
From: hankd@dynamo.ecn.purdue.edu (Hank Dietz)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Compiler Costs
Summary: In the long run, compilers win
Message-ID: <1990Jul8.230954.18881@ecn.purdue.edu>
Date: 8 Jul 90 23:09:54 GMT
References: <1797@apctrc.UUCP> <1990Jul6.161158.1297@zoo.toronto.edu>
Sender: news@ecn.purdue.edu (USENET news)
Organization: Purdue University Engineering Computer Network
Lines: 48

In article <1990Jul6.161158.1297@zoo.toronto.edu>:
>In article <1797@apctrc.UUCP> zrra07@backus (Randall R. Appleton) writes:
>>I have a simple question:  Does anyone know what sort of speed-up
>>on gets by going from a good implementation of some algorithm in a
>>third generation language (C, Fortran) and a good optimizing compiler
>>to hand-coded assembly?
>
>It can be negative.  Good optimizing compilers can often do a better
>job on large bodies of code than humans can.  Small code fragments
>often do better when carefully crafted by humans, although this is
>a very time-consuming activity.

Basically, I agree.  Given the caveat that good compilers are quite
rare, I have seen good compilers consistently outperform handwritten
assembly code -- but humans could usually do local tweaks to compiler
generated code to speed it up even a little more.  IMHO, this is
primarily because compilers usually don't do a very good job of
modeling irregular or complex instructions, whereas humans often are
great at using those, but write inferior code for the more mundane
operations (e.g., they do a poorer job of allocating registers, aren't
consistent about taking advantage of some properties, etc.).  Notice
that RISC architectures don't have many "funny" instructions, so
compilers for them can do particularly well against humans....

Basically, optimized code generation is a search procedure -- if the
compiler knows to search for the right things (which is learned in
part by observing what the best human programmers do), the fact that
computers can search faster and more consistently than humans will
eventually make compiler technology generate better code than a
typical human every time.  Think about how computers play chess -- at
first, clever heuristics were best, but lately the winners have
focussed more on very fast search techniques, and now they are
generally better than most human chess players.  Yes, the very best
human chess players still win, but they are a very small group, and
each game played so carefully is a major effort (i.e., costly).  So it
is/will be for compilers versus humans writing assembly language
programs....

In any case, for good C and Fortran compilers using 1970s compiler
technology and generating code for a PDP11ish target, I'd say a factor
of 2.5x slower than carefully written assembly code is typical.  For a
compiler using 1980s compiler technology (there are very few of these)
and targeting a RISC machine, I'd say it's common to be 30% or more
*faster* than hand-written code (assuming a dumb, non-optimizing,
assembler).  Of course, there are billions and billions of caveats on
these numbers....

						-hankd@ecn.purdue.edu