Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!rice!titan.rice.edu!preston
From: preston@titan.rice.edu (Preston Briggs)
Newsgroups: comp.lang.misc
Subject: Re: Compiler Costs
Message-ID: <9747@brazos.Rice.edu>
Date: 11 Jul 90 06:29:17 GMT
References: <1797@apctrc.UUCP> <2317@l.cc.purdue.edu> <2681@awdprime.UUCP>
Sender: root@rice.edu
Distribution: na
Organization: Rice University, Houston
Lines: 29

In article <2681@awdprime.UUCP> tif@doorstop.austin.ibm.com (Paul Chamberlain) writes:

>>> In other words, if I take my average well written program, compiled
>>> with a good optimizing compiler, and re-write it in assembler, what sort

>Anyone will tell you though that you usually only need to
>rewrite a couple dozen lines to get your 2-3 times faster.

Anyone?  Not me.  I think you're exaggerating the speedup
and minimizing the amount of rewriting.

The programs I work on aren't huge -- certainly all less than 10,000 lines.
But there aren't 24 lines that consume 50 to 67 percent of the time
(assuming you could replace them with assembler that executes in 0 time).
There's a lot of work being done by many different pieces of the code,
each consuming some fairly small percentage of the total time.

A smaller program doing something simple (sort this file, format this
text, or whatever) might could be sped up a significant amount.
For large programs (particularly "well written," that is, using the right
algorithms), I'd be suprised if you can get a factor of 2 without
major effort.

Thinking in terms of the 80-20 "rule", 20% of 10,000 lines suggests
we might look for the 2,000 most executed lines.  That's a lot of rewriting!

--
Preston Briggs				looking for the great leap forward
preston@titan.rice.edu