Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!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: 6 Nov 90 18:17:31 GMT References: <5008@lanl.gov> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 74 Nntp-Posting-Host: odin In-reply-to: jlg@lanl.gov's message of 5 Nov 90 22:15:54 GMT On 5 Nov 90 22:15:54 GMT, jlg@lanl.gov (Jim Giles) said: jlg> From article , by jlg> pcg@cs.aber.ac.uk (Piercarlo Grandi): pcg> [...] Now, the interesting question is how much of a liability in pcg> terms of reduced confidence is aggressive optimization. Reasoning pcg> shows that in way of principle it lowers the reliability of a pcg> compiler. Show that this is not true, or that if true there are pcg> compensating advantages, and quantify your argument. jlg> You are making the assumption that optimization techniques reduce jlg> the reliability of the compiler. This is certainly true for jlg> esoterica. But, you have also attacked the old standby techniques jlg> as well. Whether the technique is well understood or not does not matter that much -- the *algorithm* may be perfectly safe (even if proving so in the context of a language whose semantics have not been designed for transformations is quite hard, even for seemingly simple things like common subexpression elimination); the hazard comes from the amount of code needed to implement it. The code may be buggy -- actually *it will*. More code, more bugs. Do we want 100 thousand lines of compiler to debug when 10 thousand would do it? No... Naturally not all those 100 thousand are involved in the critical translation business, but the translation business had better be as streamlined as possible. More code more bugs, no question about it. It is not an assumption. Anything that is not related to straight translation means more bugs. jlg> If I were writing a compiler for _reliability_ alone, I would jlg> certainly make a complete data flow graph and a complete analysis of jlg> control flow. These techniques have been around for decades, are jlg> stable, and much theoretical work (including correctness proofs) has jlg> been done: But these techniques require pretty long and elaborate code. Again, if we assume (and this is indeed a crazy assumption) that we can find an algorithm to perform hairy transformations without making mistakes and then implement the algorithm without bugs, then aggressive optimization is a no-loss situation (except for compile time and space), and whatever its benefits on run time and space we shoudl do it. It also wins if we think the program is a "dusty deck" or the programmer is a "dusty programmer". But in the latter case programmer's assistants at the source level seem an even better win. jlg> in short, they are the most reliable tool after automatic jlg> parser generators that are available in compiler work. This is a quite extraordinary statement -- you may be implying that parsing C's syntax, which has been designed for easy context free LL(1) parsing, is something as straighforward and reliable as rewriting sequences of C's statements, which have not been designed for it? (note that C's *expressions* have actually been designed for rewriting, instead) jlg> So, don't pretend your objections are based soley on reliability. Never claimed this -- the claim is that anything that complicates a crucial system component like a code generator without demonstrated and quantified cost/benefit analysis should be treated with caution, especially if the complication is about doing something that was not anticipated at design time. My argument is that such potentially risky business should be a separate program, that it is the responsbility of the programmer to invoke, guide, and where the programmer has to check the results. This may look like too much work, but aggressive optimization is expected to make a significant difference, like most any optimization, in a few cases, and these may deserve attention. -- 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