Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased From: chased@rbbb.Eng.Sun.COM (David Chase) Newsgroups: comp.lang.misc Subject: Re: Aggressive optimization Message-ID: <1932@exodus.Eng.Sun.COM> Date: 1 Nov 90 23:46:28 GMT References: <2301@wn1.sci.kun.nl> <8960018@hpfcso.HP.COM> <1990Oct30.105241.9733@tkou02.enet.dec.com> <1849@exodus.Eng.Sun.COM> Sender: news@exodus.Eng.Sun.COM Organization: Sun Microsystems, Mt. View, Ca. Lines: 87 pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >chased> The compiler-writer's claim is "I can prove that these >chased> optimizations conform to the standard"; >STOP THE PRESSES! Compiler writer proves that he can do program >rewriting in a bug free way! Program synthethizers must be round the >corner! Major software companies stocks collapse! Read your own posting, please, and note that what you quote did not say what you say it said. "I claim I can prove" is most definitely not the same as "I have proved". It means that the steps in optimization are based on little proofs, and sketches of proves; it doesn't mean that there is a big book proving the compiler correct. Such a book *could* be written if the need existed (the existance of dire need would be demonstrated by the exhibition of wheelbarrows full of money to finance its writing). Note, too, that I never claimed that the optimizations performed, however aggressive, are anywhere near general-purpose program rewriting or program synthesis. I have claimed, and will continue to claim, that what transformations are performed are based on a carefully worked-out understanding of certain program transformations. Regarding the virtual-machine-to-physical-machine mapping, if the standard only specifies that we must reproduce the I/O and approximate resource consumption of the virtual machine, then that's what we'll do if it makes the code faster. Where does it say that we should not do this? And, regarding, the tobacco industry analogy (an ad hominem analogy, too -- aren't vile insults what one uses when arguing from a weak position?), I will suggest that you have no evidence, only anecdotes, for the alleged pervasive bugginess of optimizing compilers. Certainly you have nothing like the evidence gathered to demonstrate a connection between tobacco and lung disease, and only hand-waving claims as to the cause-and-effect link. I *am* selling my skills, but I fail to see that there is anything pernicious about that. I think it is also true that new compilers will be both more aggressive and less buggy; if nothing else, the test suites only grow larger and more comprehensive, and faster, cheaper machines allow more tests to be run in a given amount of time, and wished-for and formerly ad-hoc optimizations are being backed up by better theory. The need for better compilers will also increase with time as clock rates and potential parallelism increase (both of these things pound harder on memory, and increase the gains of good register allocation and locality-enhancing transformations). It is also unclear that your claims about the speed/risk trade-offs are in any way connected with reality. Speed gained for you by an optimizing compiler is speed that you don't have to work for by hand-coding (though both can be used together to get even more speed-up if that is necessary), and the time saved by the programmer is more time that can be spent debugging and testing the code. Every programmer I know has a bug introduction rate higher than any compiler that I've ever used (but this is purely anecdotal -- perhaps it is completely different for other people, eh? do *you* find more compiler-introduced bugs than author-introduced bugs in *your* code?), so it is in fact more reliable to let the compiler do the optimizing, even if you don't use the time saved for additional testing and debugging. Now, I will grant one important thing, which I think is also important to you -- if I had garbage collection, I would be a more productive programmer. Garbage collection is available for "C", but it is potentially broken by optimizing compiler for C, which means that one powerful productivity and bug-avoiding aid is unavailable if you optimize. However, no specification for C anywhere in existence guarantees that a garbage collector should be able to function, and most programmers do not take advantage of garbage collectors, and some programmers write (perfectly legal) code that is guaranteed to break a collector at any level of optimization. It pains me that this is the case, but it is so, and if it increases the SPECmark to break a non-standard piece of code, even a useful one, that piece of code will be broken. There's always Lisp, ML, Eiffel, Russell, Modula-3, and Miranda. I've said several of the things that I said in this article before -- you might seriously consider comparing the bug-introduction rate of programmers, both skilled and ordinary, with the bug-introduction rate of several "aggressively optimizing" compilers. You might also check to see if there are any trends in compiler bug rates over time, and see how that correlates with the optimizations performed by those compilers. I think you'll find that your claims are not supported. David Chase Sun Microsystems, Inc.