[gclist] Re: gclist-digest V2 #110

[Bob Kerns]

I'm not saying there's no merit in your point, but...

You also need to factor in the risk of inaccurate estimation of the
probabilities.

For example in the GC case, it is tempting to assume uniform
distribution of numerical values, but this is wildly inaccurate.

It is *very* difficult to accurately determine the probabilities on
something like this. The analysis can be much more complex than the code
it would replace!

Another factor to consider is the cost of *debugging* something like
this, if it does arise. I've seen similar reasoning be flawed, and the
resulting problems were *not* easy to track down..

Yes, your complicated code may have a greater than 1 in 10^n chance of
being wrong. However, if it is, you have a much better chance of being
able to test for the defect and fixing it. Once fully tested and fixed,
the probability of a defect drop to zero. The hard part is determining
when you've fully tested it. A good coverage tool, like VisualCoverage
from tracepoint.com is invaluable here!

As a general rule, I think that with good testing techniques, the risk
of bugs can usually be reduced to *below* the risk of mis-estimating the
probabilities, and the cost can be reduced to a reasonable level.

But in cases where the downside risk is small (needing to retry an
operation, say) and the cost of the alternative high, there can be merit
to this.

But I wouldn't want my life-support system coded to this standard.

But as to Emacs, I'd have to say that I'd rather risk occasional bloat
than occasional death. The consequences of a bad exact GC are far worse
than the consequences of an overly-conservative GC. With current memory
and VM sizes, Emacs is about 1.5% of my VM and not much more of my RAM
requirements. I think the risk of fatal bugs would outweigh the risk of
inefficient memory usage.

Obviously, this is all opinion, and your mileage may vary.

	-----Original Message-----
	From:	Arch Robison [SMTP:robison@kai.com]
	Sent:	Thursday, January 22, 1998 06:34
	To:	gclist@iecc.com
	Subject:	%%:  [gclist] Re: gclist-digest V2 #110

	> >If I were the on the development team, it would not be
difficult 
	> >to decide whether I want to spend more time now debugging a
precise
	> >collector where I have control over all aspects of the
problem or
	> >whether I want to spend much more time later trying to
provide a way
	> >to tweak that 1 in 1,000 heap that I have no control over
(times a
	> >million+ users) that leaks so bad you have to restart every
hour... 

	The "1 in 1,000" raises a question: what is the real
probability,
	and if known, is it acceptable?  On one project, I was faced
with
	implementing something either using a simple technique with a 
	random 1 in 10^n chance of failure, or a complicated technique
	with no (obvious) chance of failure.  I had control of n.
	I decided on the simple technique because it would result in a
more
	reliable system.  Why:

		1) Extra time spent on the complicated technique could
otherwise
		   be spent more profitably on fixing known bugs that
occur
		   much more frequently than 1 in 10^n.
		   
		2) Given my track record on writing perfect code, it was
likely
		   that the complicated technique was going to end up
failing
		   more than 1 in 10^n.
		   
	It is true that the number of users and runs per users makes a
difference.
	And the probabilities are often difficult to figure.  But if the
true 
	probability is actually quite small relative to other problems
in the
	system, then worrying about that is almost surely misplacing
one's attention.  
	Worrying about absolute perfection is the province of academics.
	In the industrial world, we have to evaluate relative risks.

	- Arch Robison