Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: Compiler Costs
Message-ID: <2331@crdos1.crd.ge.COM>
Date: 9 Jul 90 15:47:00 GMT
References: <1797@apctrc.UUCP> <373@e2big.mko.dec.com> <2319@l.cc.purdue.edu> <9730@brazos.Rice.edu>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 21

In article <9730@brazos.Rice.edu> cliffc@erato.rice.edu (Cliff Click) writes:

| Looking at what some compilers produce (say, at least 6 commerical ones) I can
| get a factor of 2 speedup by doing "stupid" optimizations, that I would expect
| the compiler to get on it's own.  To get better than that I cannot color 
| within the compiler's lines, but generally I need to restructure how things
| are solved - not nessecarily a change of algorithms but a change of *structure*.

  Yes to both ideas. I was doing a Mandelbrot program and when I had
done all I could to speed it up, I output the assembler code to a file,
optimized it by hand, and got a 45% reduction in CPU time. However, I
had alread gotten a 60% reduction by improving the algorithm and the
implementation in C.

  While there is room for notable improvements when you have a small
routine called 600 million times, in general the real savings comes from
improving the overall algorithm to reduce the work to be done.

-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
            "Stupidity, like virtue, is its own reward" -me