Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!hellgate.utah.edu!csn!boulder!uswat!gbeary From: gbeary@uswat.uswest.com (Greg Beary) Newsgroups: comp.software-eng Subject: Re: Effect of execution-speed on reliability/testing Message-ID: <14220@uswat.UUCP> Date: 9 Jan 91 19:47:57 GMT References: <1990Dec19.102005.11830@engin.umich.edu> <470@eiffel.UUCP> <14141@uswat.UUCP> <11541@pt.cs.cmu.edu> Sender: news@uswat.UUCP Organization: US WEST Advanced Technologies, CO, USA Lines: 67 In article <11541@pt.cs.cmu.edu> tgl@g.gp.cs.cmu.edu (Tom Lane) writes: >In article <14141@uswat.UUCP>, gbeary@uswat.uswest.com (Greg Beary) writes: >> > >> >How about Michael A. Jackson's two rules of optimization: >> >Rule 1: Don't do it. >> >Rule 2: Don't do it yet. >> >from _Principles of Program Design_, chapter 12. >> >> My personal experience in realtime systems is just the opposite, and >> just as mis-leading. When working for a IBM-compatible hardware company >> the Disk-folks were selecting new micro-processors. The criteria was >> "the fastest is the best". >> >> This begged the question, "how fast does it have to be". The answer was >> "as fast as we can get". I think we need to add a healthy dose of >> engineering into this discussion, so we can understand "how fast does it >> have to be". > >Amen. Here's a relevant engineering opinion: > >P. J. Plauger has an excellent article on just this topic in the Jan '91 >...lines deleted > The cost of programming any resource rises rapidly once you > use up about 70% of that resource. > > >I'm not sure where Plauger got the 70% figure from; he cites no >references. Maybe the curve doesn't really take off until 90%; or maybe >you want to figure 50% to give yourself some room for estimation error. >In any case the general principle is surely correct. > Many years ago I did a bit of capacity planning for large data centers. The 75% mark was noted as a decision point. It was at that point in time that you had better be planning what your next upgrade was going to be. By the time you reached 85% utilization the problem was very apparent to your users (spikes took utilization above 85%). As you approached 90-95% utilization things got really bad, and above that they got to be damn near ridiculous. I don't know where Plauger got his numbers, but there was lots of empirical data around the capacity planning world to support the idea. I return to my central point, whether it be real-time or commercial software, most designers have no idea what the resource constraints are. Further, its been my experience that performance estimation is difficult and not much fun, so people don't do it. The folks I knew chickened-out and just assumed that if they didn't know how fast it had to be...buying the fastest available was the best they could do (ie. no one would be able to moan about the choice). This is similiar to buying a Ferrari to commute to work in... if late, you might want to get there in a hurry. This allows for three results: You may never be late. The Ferrari, at 160 mph, gets you there. Or, you're 2 hours late and even the fastest car can't get you there on time. Most of us won't opt for such an expensive solution. It's funny though when other people's money is on the line (ala shareholders) the same frugallity doesn't seem to be shown. If we want to be treated like engineers we ought to act like engineers. -- Greg Beary | (303)889-7935 US West Advanced Technology | gbeary@uswest.com 6200 S. Quebec St. | Englewood, CO 80111 |