Path: utzoo!attcan!uunet!decwrl!bacchus.pa.dec.com!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (Real Amigas have keyboard garages) Meyer) Newsgroups: comp.arch Subject: Re: Compiler Costs Message-ID: Date: 11 Jul 90 16:12:02 GMT References: <1797@apctrc.UUCP> <759@bbking.KSP.Unisys.COM> Sender: news@wrl.dec.com (News) Followup-To: comp.arch Organization: Missionaria Phonibalonica Lines: 32 In-Reply-To: rmarks@KSP.Unisys.COM's message of 9 Jul 90 14:15:12 GMT In article <759@bbking.KSP.Unisys.COM> rmarks@KSP.Unisys.COM (Richard Marks) writes: Moral: Consider implementing in your favorite higher level language; but then recode the inner loops in assembler for perfromance. You missed a step - instrument the code to find out where the time is really being spent, and why. Your intuition about that is probably wrong. And since no such statement is complete without anecdotal evidence, here's mine: I had software that was doing strange floating point calculations. 80+% of the cpu time was spent inside an inner loop. 90+% of the time in the loop was spent in a system function. Changing the inner loop to precompute the 50 or so values it needed and using a lookup table basically eliminated that 90%, giving me a speedup of 3-4 times. If I'd just rewritten the inner loop in assembler without instrumenting it, and done an excellent job of it, I'd have improved the speed of the 10% of the loop by an order of magnitued, giving me code that ran maybe 8% faster. Instrumenting took less time than an assembler rewrite and the lookup change was trivial. Not that rewriting in assembler isn't sometimes the right solution. In this case, improving the algorithm was the right solution. But the right first step is always to instrument things so you know you're solving the right problem.