Path: utzoo!attcan!uunet!aplcen!haven!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc Subject: Re: Aggressive optimization Message-ID: <2669@l.cc.purdue.edu> Date: 22 Oct 90 14:00:51 GMT References: <13405:Oct1800:22:5690@kramden.acf.nyu.edu> <66071@lanl.gov> Organization: Purdue University Statistics Department Lines: 66 In article , jdarcy@encore.com (Floating Exception) writes: > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >In article <66071@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > >> _ALL_ production quality compilers I've ever used on mainframes can do > >> much better than all but the most adept programmer at this optimization. > >> Further, the adept programmer can usually do no better than the compiler. > > >What?! This is absolutely unbelievable. In one of my last few articles I > >had a paragraph listing some of what a competent hand optimizer does > >regularly. A simple example > > [convoluted example] > >A less trivial example: In a heavily hand-optimized implementation of > >Nussbaumer's convolution method > > Give us a break, Dan! Both of the examples you've given represent changes > of *algorithm* based on foreknowledge of possible input values, a type of > optimization of which nobody expects compilers to be capable, at least not > in this century. I guess in some distant future there will exist compilers > that can recognize and replace inferior algorithms with more efficient ones, > but that's irrelvant to your disagreement with Jim Giles. What he was > talking about was an optimization that, in essence, merely rearranges the > order of evaluation of intermediate results. As I have stated before, the specific hardware configuration can have a major effect on the relative performance of algorithms. I am even more pessimistic than you about automata taking into account this information. But even other decisions as to when and how to do weird unrolling, or can conditional transfers on planned exceptions be combined, etc., are unlikely to be made by automata. I can revise an algorithm to take into account the size of an instruction stack or interference by doing things which the compiler cannot know are possible. The real solution is to have the programmer and the compiler interact. The compiler can systematically look at millions of options, but it cannot innovate. The human mind has great flexibility, but is not particularly fast at routine. > I think most people admit that your obviously high opinion of your own > programming skills may not be entirely unjustified, but not everyone is > so talented. There are many programmers out there who simply don't do > even the simplest types of hand optimizations, who write really crappy > code, and because they are so numerous I would say that it's perfectly > reasonable for compilers to optimize as aggressively as their creators > can make them. Obviously, this should be done without sacrificing any > correctness, and may not do much for "adept" programmers, but for the > code produced by run-of-the-mill types optimization has always been a > very big winner. I suspect that he is not bragging but complaining. If you teach potential programmers that "these are the ways things are done, and these are the concepts you can use in your programs," you make it difficult for them to even think later. As many have said, "It ain't what you don't know that hurts you, t's what you know that ain't so." Talent can be destroyed more easily than it can be created. To start a potential programmer with a set of techniques designed for those who cannot think is to at least bury the potential for thinking. My exper- ience with students who have had computational courses in mathematics and statistics is that the situation is much worse. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)