Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!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: 7 Nov 90 16:14:34 GMT References: numerous <2182@exodus.Eng.Sun.COM> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 123 Nntp-Posting-Host: odin In-reply-to: chased@rbbb.Eng.Sun.COM's message of 6 Nov 90 01:21:12 GMT On 6 Nov 90 01:21:12 GMT, chased@rbbb.Eng.Sun.COM (David Chase) said: chased> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> Point taken. However, *you* (not you personally, of course) are pcg> proposing new untried and potentially hazardous technology. The pcg> burden of proof in on you and your customers. chased> I don't think that the technology is as new or untried as you chased> seem to think. Well some of it is. All the parts where one is trying to do serious program rewriting are akin to program synthesis, which is still way from anything I would depend on. Also, the point is that it is not *necessary*; it is only used for cost/benefit reasons. It remains to be shown that the costs are greater than the benefits. Jim Giles says that any optimizer that is not bug free is _broken_, and thus (I guess from his tone) irrelevant to our discussion. He therefore dismisses a large part of the cost side of the equation, which is a bit too easy. chased> The set of optimizations that one hopes a modern compiler would chased> perform [ ... have been with us for a long time and thus ... ] chased> are no more "potentially hazardous" than scanning and parsing. Ahem. Scanning and parsing are usually context-free, they do not involve any interpretation of the input (semantics), their algebras are very well understood indeed and fairly simple, etc... -- I would grant though that code generation is approaching the level of confidence of parsing and scanning (thanks to the works of people trying to automate as much of it as possible), but even that is subject to doubt. But I concede that many of the optimizations that you mention are indeed 'traditional'; given sufficiently large amounts of time, talent and effort they could be performed reliably inside a code generator. But then my second level of argument is triggered -- they may have become cost-effective for the user (visible performance gain, small reliability loss), but is it true that investing in an aggressive optimizer is the best way to achieve that user level cost-effectiveness? Better training may give greater and longer lasting benefits, using higher level languages may give greater and longer lasting benefits, source level programmer's assistant may give greater and longer lasting benefits. All such technologies are tested and proven (except for programmer's assistants, unfortunately). Better training and use of higher level languages do not apply to the "dusty deck" and "dusty programmer" problems, admittedly, so there aggressive optimization may be justified, but even then there is some reason to think that programmer's assistants and source rewriting may be preferable to aggressive optimization, and mor eresearch on that may pay off better than more research on aggressive optimization. pcg> For starters I produce the general principle that a bigger and more pcg> complicated program, unless proven otherwise, has to be presumed to be pcg> buggier. chased> Agreed, generally true. A quick glance around the programs that chased> I run every day reveals that the (text of the) optimizer (for C, chased> Fortran, Pascal, and Modula-2) is smaller (often by an order of chased> magnitude) than vmunix, gnuemacs, dbx, cfront, and several chased> language front ends. But these comparisons are not that meaningful! Bugs in the editor and in the debugger are not as dangerous as those in the compiler. Bugs in the OS are almost as dangerous though. Also, a lot of these programs is relatively trivial and unimportant -- almost all of an aggressive optimizer is critical. Not every type of program has the same bug intensity -- scanners and parser can be reasonably expected to have much less bug intensity than optimizers, and whatever they intrinsic complexity they are in any case *necessary*. An optimizer is not *necessary*; especially not an aggressive optimizer, give that there are alternatives. A code generator, a parser and a scanner and symbol table management are necessary. The argument is not, I repeat here for the millionth time, that optimizers are useless or infinitely buggy or otherwise that if they are perfect using them is a no loss situation -- it is that, since they are not necessary, and they are very critical, they must be *proven* to add more value (performance) than they subtract (*extra*, avoidable bugs), and that their effect is not best achieved by other means. chased> So, should I worry more about bugs in the front ends, bugs in chased> the editor, bugs in the OS, bugs in the debugger, or bugs in the chased> optimizer? You should worry a lot about them too! I am no less unhappy about the size of vmunix, GNU Emacs, gdb and so on than about the size of gcc and cfront and accomplices. Indeed I am consistent in other newgroups in complaining about the large increases in complexity and unreliability, with little gain in performance (or loss of it) or in functionality, that these programs give, and offering examples of equivalent technology that is better designed and provides the same benefits at lower cost. RISC software! chased> Although, if people cared that much more about reliability than chased> they do about speed, I think we'd see a lot more people chased> programming in languages other than Fortran, C, and C++. Of chased> course, that's another discussion, but it probably gives some chased> indication of what people expect from their compilers (besides chased> perfection, of course). Let's be temporarily diverted to that other, sociological discussion: If they cared about speed almost all programmers would be much better off if they used a higher level language and left code generation to the compiler, or to a programmer's assistant, or to the authors of a library. What instead they expect is to write poor code themselves and have a magic optimizer substitute it with the better code that a higher level language would have more economically and reliably translated into. To get back to the admittedly exxagerated tobacco industry analogy -- if smokers cared about their health, they would be eating carrots instead, but they don't. This is maybe a good reason to be a cigarette manufacturer (there is a market demand) but maybe not a good reason to say that if people don't care about a problem it is irrelevant. -- 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