Re: Fast code vs. fast compile

mwolfe@dat.cse.ogi.edu (Michael Wolfe)
22 Jan 1997 00:04:46 -0500

          From comp.compilers

Related articles
Beginner's Question... mihai@A-aod.resnet.ucsb.edu (Mihai Christodorescu) (1997-01-16)
Fast code vs. fast compile dennis@netcom.com (1997-01-16)
Re: Fast code vs. fast compile salomon@silver.cs.umanitoba.ca (1997-01-19)
Re: Fast code vs. fast compile darius@phidani.be (Darius Blasband) (1997-01-22)
Re: Fast code vs. fast compile jlilley@empathy.com (John Lilley) (1997-01-22)
Re: Fast code vs. fast compile mwolfe@dat.cse.ogi.edu (1997-01-22)
Re: Fast code vs. fast compile mikey@ontek.com (1997-01-22)
Re: Fast code vs. fast compile conway@cs.mu.oz.au (1997-01-22)
Re: Fast code vs. fast compile darius@phidani.be (Darius Blasband) (1997-01-25)
Re: Fast code vs. fast compile wws@renaissance.cray.com (Walter Spector) (1997-01-25)
Re: Fast code vs. fast compile kanze@gabi-soft.fr (1997-02-16)
| List of all articles for this month |

From: mwolfe@dat.cse.ogi.edu (Michael Wolfe)
Newsgroups: comp.compilers
Date: 22 Jan 1997 00:04:46 -0500
Organization: Oregon Graduate Institute (OGI), Portland, Oregon
References: 97-01-122 97-01-137
Keywords: performance

Having seen this discussion arise in person or on the network every
couple years, I view this with some amusement. Many academic compiler
developers view concern about compile time with disdain, with the
standard arguments ("compile time is unimportant, the program will be
run many more times than it is compiled" etc. etc.). I've developed
some real slow compilers, and made all these arguments (my slowest
compile was 30 CPU minutes for 4 lines of code ... slow even on an old
IBM 360/75 ... some real dumb compiler algorithms in those days).
Well, academic research compiler projects are pressing the limits of
what can be done automatically; in that frameowrk, compiler speed is
not of primary importance. However, having worked in the compiler
industry, trying to SELL compilers, and having watched many other
hardware and 3rd-party compiler vendors start up and succeed or fail,
I can say that experience demonstrates that compile time IS very
important to commercial success. Multiflow had a very powerful, very
well engineered compiler, but unfortunately, a very slow one (hundreds
of lines per minute, about 5-10x slower than their competitors at the
time). The compile time really hurt them, right in the pocketbook,
and in the commercial world, that's what counts. When I was first
developing commercial compilers, the compiler speed was a CRITICAL
factor to its success and adoption by others, right after correctness,
and measured right next to performance. When the Cray CFT compiler
(written in Cray Assembler) was being replaced by the CFT77 compiler
(written in Pascal), the users complained bitterly that the compile
speed dropped by 1/2 from 200,000 lines/minute down to 100,000 lines
per minute (count the zeros).


YOU, random single user, may not really care about compile time, until
it gets REAL slow, but YOU are not going to buy many compilers, are
you. In fact, YOU probably use 'gcc', so you're not going to buy ANY
compilers. People who need compilers are those who use them, and are
very sensitive to response time. I know of one commercial compiler
development group in another state that uses a 3rd party compiler to
develop their own compiler, because their own compiler is too slow.


-Michael Wolfe
  formerly Professor, Oregon Graduate Institute
--
- Michael Wolfe (mwolfe@cse.ogi.edu)
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.