Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!decwrl!orc!Ozona!chase From: chase@Ozona.orc.olivetti.com (David Chase) Newsgroups: comp.lang.misc Subject: Re: Common subexpression optimization Message-ID: <48942@ricerca.UUCP> Date: 6 Feb 90 19:09:53 GMT References: <4561@scolex.sco.COM> <14214@lambda.UUCP> <2217@sunset.MATH.UCLA.EDU> <4466@brazos.Rice.edu> <4467@brazos.Rice.edu> Sender: news@orc.Olivetti.Com Reply-To: David Chase Organization: Olivetti Research California, Menlo Park, CA Lines: 49 Summary: Expires: Sender: Followup-To: In article pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: > Strength reducers are good enough that I don't need to mess > with pointer variables. Various forms of redundancy elimination > are good enough that I needn't bother about every little common > subexpression. Vectorizers are good enough so that I need not > manually insert vector primitives. Register allocators are > good enough that I need not scatter register declarations about. > >About the "good enough" I am somewhat skeptical (especially about >the register allocators -- but then again, many modern machines >have more registers than variables...). Also, most of the time >these optimizations are irrelevant. Interesting assertion -- do you have references to support this? Especially, do you have evidence that vectorization is usually irrelevant? >It [optimization] encourages less precise coding, and makes the >compiler many times larger, and these are *very* bad news, and very >costly too. All this to optimize very little pieces of code, which >could be manually sorted out, and with improvement on their >information content for both humans and programs that read them. (1) Large costly compilers are only "bad news" if few programs are developed -- once a compiler is widely used, the extra time spent in its development is paid back many times over. (Of course, first you have to get the compiler into wide use.) (2) Why do you assume that "precise coding" is good? Does it get a program written more quickly, or make the program more maintainable, or more likely to be correct, or increase its portability? In general, the answers are NO, NO, NO, and NO. At best, "precise coding" will make code run faster on one machine with one particular compiler. A good optimizing compiler can do just as well, with less time spent doing it. (Note -- you perhaps regard optimizers as program-manglers; for C, you have no grounds for complaint, since (last I heard) the language standard is not yet official -- if you program in a language with no official definition, you should expect some variation in the implemented semantics. Nobody forced that choice on you.) A high-powered optimizer does allow programmers to get a program running efficiently with less time spent thinking about it. This is bad? We should program more slowly? *Some* people use the extra time to worry about higher-level issues, like correctness and algorithmic complexity. Some programmers aren't that thoughtful -- would you trust such a person to hand-optimize code? David