Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!uwm.edu!rutgers!rochester!pt.cs.cmu.edu!g.gp.cs.cmu.edu!tgl
From: tgl@g.gp.cs.cmu.edu (Tom Lane)
Newsgroups: comp.software-eng
Subject: Re: Effect of execution-speed on reliability/testing
Summary: The 70 percent rule
Message-ID: <11541@pt.cs.cmu.edu>
Date: 9 Jan 91 17:32:33 GMT
References: <1990Dec19.102005.11830@engin.umich.edu> <470@eiffel.UUCP> <14141@uswat.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 76

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
issue of _Embedded Systems Programming_.  He puts forward something he
calls the Seventy Percent Rule:

	The cost of programming any resource rises rapidly once you
	use up about 70% of that resource.

For "resource" read "available CPU time", "disk space", etc.  You spend
your time in trying to shave usage, improving resource-exhaustion error
recovery algorithms, and so on.  As you get closer to 100% utilization,
development cost and system unreliability increase exponentially.

A corollary to this is that you need to choose an adequately powerful
mechanism: fast CPU chip, large disk, etc.  Plauger illustrates this
with the issue of operations that have to be performed within some
specified time after receipt of a trigger signal.  Among the possible
software mechanisms (assuming a Unix-like OS) are:
  1. Interrupt handlers inside the kernel;
  2. A waiting process, locked in core;
  3. A process ready to run, but possibly swapped out;
  4. A program (or even shell script) to be started on demand.
Plauger says you should "choose the slowest mechanism that is fast
enough.  By fast enough, I imply that you allow plenty of headroom, in
accordance with the 70% rule."  This gives you the easiest-to-program
alternative, because (a) you don't use a more restrictive mechanism than
necessary, and (b) you don't get into the expensive close-to-the-
resource-limit style of programming.  Picking a level that is just a bit
too slow is a common mistake: it looks like it will work, but the costs
of programming at 95% (or 105%) of the resource limit will kill you.

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.

This can actually be read as supporting Jackson's rules against
optimization, if you define "optimization" to mean the kind of marginal
fiddling that people tend to do when they are close to a resource limit.
Plauger is advocating intelligent consideration of performance
requirements in the initial system design, so as to *avoid the need for*
that kind of optimization.  Unfortunately, as a previous poster already
pointed out, some people think proper design means no consideration of
performance at any time.  That is a recipe for failure.

It's not clear to me how Plauger's principle applies in situations where
there's not a hard resource limit.  In real-time-response systems there's
usually a very clear speed threshold: when you miss incoming data, or
fail to stop the conveyor belt in time, you're too slow.  In systems
where 5% slower than the originally specified speed is not catastrophic,
the exponential effort curve may not apply.  Any comments?

-- 
				tom lane
Internet: tgl@cs.cmu.edu
UUCP: <your favorite internet/arpanet gateway>!cs.cmu.edu!tgl
BITNET: tgl%cs.cmu.edu@cmuccvma
CompuServe: >internet:tgl@cs.cmu.edu