Path: utzoo!attcan!uunet!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: <2213@exodus.Eng.Sun.COM> Date: 6 Nov 90 18:28:47 GMT References: <1849@exodus.Eng.Sun.COM> <1932@exodus.Eng.Sun.COM> <2303:Nov607:26:0890@kramden.acf.nyu.edu> Sender: news@exodus.Eng.Sun.COM Organization: Sun Microsystems, Mt. View, Ca. Lines: 43 brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >chased@rbbb.Eng.Sun.COM (David Chase) writes: >> I will suggest that you have no evidence, only anecdotes, >> for the alleged pervasive bugginess of optimizing compilers. > >He says this while another comp.lang.c poster complains about an >optimizer bug, while I find that a new optimizer crashes on an empty >loop, and while someone else sees an optimizing Fortran compiler that >still produces incorrect code for overly complex control structures. That's still just anecdotes. You've found what, maybe one bug per compiler? That's not pervasive. Note the nature of the bugs -- you've got one bug in a beta-test compiler (GCC -- this is not a slam on GCC either; most people don't release their beta compilers for the world to tinker with), one bug that, though annoying, won't cause you to go debugging down a rathole, and one bug that will actually cause a programmer to waste time. I'd call that last bug serious. I've never claimed that optimizers were bug-free, but I will claim that the bug rate is acceptably low for the improved performance that they offer, especially if compared with other methods of obtaining that performance (i.e., hand-tweaking of assembly language, source-to-source transformations). People make mistakes. Furthermore, in the sad event that a compiler has a bug in it, I can often write down description of the bug and put it on my list of things to avoid/watch for(/repair?) in the future. Human beings, however, are creative, and make *new* mistakes. People should do the optimizations that compilers cannot hope to get (i.e., selection of appropriate algorithm), and leave the repetitive twiddly stuff for compilers. Furthermore, even after extensive application of hand-optimizations, optimizing compilers can still yield performance improvements by performing optimizations not expressible (within bounds of tedium) in the source language (note that some of these optimizations still fall into the category of "aggressive" optimizations -- e.g., movement of non-volatile loads and stores for scheduling, software pipelining, tail-call elimination). Arg. I'm sure I sound like a broken record, but I'm sure glad I stayed out of the pointer-and-arrays fiasco. David Chase Sun Microsystems