Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!taumet!steve From: steve@taumet.com (Stephen Clamage) Newsgroups: comp.lang.c Subject: Re: Just rambling about optimization... Message-ID: <721@taumet.com> Date: 9 May 91 15:13:11 GMT References: <444@smds.UUCP> <186@shasta.Stanford.EDU> <3072:May700:46:3691@kramden.acf.nyu.edu> <42843@netnews.upenn.edu> Organization: Taumetric Corporation, San Diego Lines: 32 dsimon@eniac.seas.upenn.edu (Derron Simon) writes: >One utility I was looking for about a year ago is an optimizer for C code >that can parse and optimize the original source. I don't know why this hasn't >been attempted by any PD writers. It is definately non-trivial, but I'm >surprised no one has ever attempted it. I'm not surprised. It is of very little use. Gains in performance at the source code level are best achieved by choosing better algorithms. Reliable optimizations achievable by source code manipulation as you describe are done anyway by quality compilers. Many of the best optimizations depend critically on how the compiler generates code, and on the characteristics of the machine. For example, an "obvious" optimization is to jump around unnecessary code. Yet on some pipelined machines, the penalty for a jump is so high it is actually faster to execute the useless instructions. Another "obvious" optimization is to convert certain kinds of multiplication into shifts and adds. The right way to do this depends critically on the machine -- some shifts on some machines are slower than some multiplies. The compiler can do this best, and quality compilers do it. Code which is fiddled to run faster with a given compiler/machine combination may run much slower with another combination. The result of the fiddling is generally not very readable, and hard to maintain. If you can't get a quality compiler and you have positively identified a bottleneck in your code, that is the time to look for a way to improve that stretch of code. Keep the original straightforward code around and document your fiddling, so that later maintainers can understand what has happened and why. -- Steve Clamage, TauMetric Corp, steve@taumet.com