Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.misc Subject: Re: Aggressive optimization Message-ID: Date: 2 Nov 90 23:36:20 GMT References: <2301@wn1.sci.kun.nl> <8960018@hpfcso.HP.COM> <1990Oct30.105241.9733@tkou02.enet.dec.com> <1849@exodus.Eng.Sun.COM> <1932@exodus.Eng.Sun.COM> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 128 In-reply-to: chased@rbbb.Eng.Sun.COM's message of 1 Nov 90 23:46:28 GMT On 1 Nov 90 23:46:28 GMT, chased@rbbb.Eng.Sun.COM (David Chase) said: chased> 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"; pcg> STOP THE PRESSES! Compiler writer proves that he can do program pcg> rewriting in a bug free way! Program synthethizers must be round the pcg> corner! Major software companies stocks collapse! chased> Read your own posting, please, and note that what you quote did not chased> say what you say it said. "I claim I can prove" is most definitely chased> not the same as "I have proved". Ahem. Agreed, it is not the same. This is a bit too easy... :-) chased> It means that the steps in optimization are based on little chased> proofs, and sketches of proves; it doesn't mean that there is a chased> big book proving the compiler correct. It so easy to convince oneself that things will work... chased> Such a book *could* be written if the need existed (the chased> existance of dire need would be demonstrated by the exhibition chased> of wheelbarrows full of money to finance its writing). Point taken. However, *you* (not you personally, of course) are proposing new untried and potentially hazardous technology. The burden of proof in on you and your customers. If one believes without proof, in the presence of arguments that counsel diffidence, amen. chased> And, regarding, the tobacco industry analogy (an ad hominem analogy, chased> too -- aren't vile insults what one uses when arguing from a weak chased> position?), I am sorry that it was perceived as insults and not grave humour. And certainly it was not meant to be ad hominem. Hey, I actually like David Chase (and Jim Giles). Good discussions, even if we do not necessaily agree, are excellent learning exercises, as layers of assumptions and different world views are exposed. And no doubt David Chase and Jim Giles are people one can learn from. OK? chased> I will suggest that you have no evidence, only anecdotes, chased> for the alleged pervasive bugginess of optimizing compilers. For starters I produce the general principle that a bigger and more complicated program, unless proven otherwise, has to be presumed to be buggier. There is a discipline called software physics, a branch of software engineering, that collects such grim statistics. chased> Certainly you have nothing like the evidence gathered to chased> demonstrate a connection between tobacco and lung disease, and chased> only hand-waving claims as to the cause-and-effect link. There is a large body of evidence about a strong correlation between complexity and size and bugginess (note that it seems that over a program's lifetime the number of bugs seems to be related *only* to its size and complexity, not to debugging effort, etc..., for a given level of programming expertise). chased> I *am* selling my skills, but I fail to see that there is chased> anything pernicious about that. Nothing wrong about that, except that your compilers do not carry the warning "The President of ACM reminds you that aggressive optimization may be hazardous to your program's correctness" :-). Again you have to prove or at least argue that the well known general principle that bigger and hairier means buggier does not apply to your aggressive optimizers. If you were using the same technology in source level rewriting assistants things would be different -- the burden of ultimate responsibility for the program logic's reliability shifts from you to the programmer. chased> It is also unclear that your claims about the speed/risk trade-offs chased> are in any way connected with reality. Speed gained for you by an chased> optimizing compiler is speed that you don't have to work for by chased> hand-coding (though both can be used together to get even more chased> speed-up if that is necessary), and the time saved by the programmer chased> is more time that can be spent debugging and testing the code. Again, what about the alternative of unbundling the risky rewriting logic from the compiler and putting it in a source level rewriting assistant? This is my favourite alternative. You could have as much fun and business (and probably more) writing a source level rewriting assistant as an aggressive optimizer, and it would be cleaner engineering, and probably even more effective as to results. chased> Every programmer I know has a bug introduction rate higher than chased> any compiler that I've ever used (but this is purely anecdotal chased> -- perhaps it is completely different for other people, eh? do chased> *you* find more compiler-introduced bugs than author-introduced chased> bugs in *your* code?), so it is in fact more reliable to let the chased> compiler do the optimizing, even if you don't use the time saved chased> for additional testing and debugging. and also: chased> I've said several of the things that I said in this article before -- chased> you might seriously consider comparing the bug-introduction rate of chased> programmers, both skilled and ordinary, with the bug-introduction rate chased> of several "aggressively optimizing" compilers. Ah no, this cannot stand. The compiler does a completely different job from the programmer -- the programmer must *invent* new code, and show ti respects some specification, the compiler must merely translate it, showing that the translation is done according to hopefully well defined rules. As long as things remain like this I am happy. Unfortunately aggressive optimization is a step away from this, because it requires an element of invention, and using less well defined rules. chased> You might also check to see if there are any trends in compiler chased> bug rates over time, and see how that correlates with the chased> optimizations performed by those compilers. I think you'll find chased> that your claims are not supported. This would be an interesting exercise for supporters of aggressive optimization. Maybe they would be able to show that the general rule is not true for aggressive optimizers, or that the increased level of problems is compensated by the gains in resource economy. Maybe not. I woudl like to remind that that I have no claims -- merely skepticism about *their* unsupported claims, and the idea that motivated skepticism counsels caution, much caution. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk