Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!firth From: firth@sei.cmu.edu (Robert Firth) Newsgroups: comp.lang.misc Subject: Re: Common subexpression optimization Message-ID: <6004@bd.sei.cmu.edu> Date: 8 Feb 90 13:04:18 GMT References: <4561@scolex.sco.COM> <14214@lambda.UUCP> <2217@sunset.MATH.UCLA.EDU> <838.18:06:33@stealth.acf.nyu.edu> Reply-To: firth@sei.cmu.edu (Robert Firth) Organization: Software Engineering Institute, Pittsburgh, PA Lines: 28 In article <838.18:06:33@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes: >Piercarlo is entirely correct. If you care about ``information hiding'' >and the ``purity'' of your code more than efficiency, you can't expect >fast code. If you can't bear to put your original code in comments and >write an efficient version with temporary variables, you don't deserve >fast code. As somebody who in his time has had to write and maintain substantial quantities of numerical software, I emphatically disagree. We are talking here about five or ten page subroutines containing some pretty complicated algebra. Radar antenna design programs, for instance, can easily have expressions extending over three or four lines of text. This code is hard to maintain at best, but one precondition for readability and maintainability is that, as far as possible, the formula written in Algol (or whatever) look as much like the formula in the book as possible. No other way can you read it, check it, or understand it. If this means that I call sin(a[i,j-1]) six times in a single expression, so be it. Optimising the code, extracting common subexpressions, calling pure functions only once, and all that stuff, is the job of the compiler. That's why it's there. That's why the first major higher-level language was called FORmula TRANslator. Don't make people fit machines; make machines fit people.