🚀 go-pugleaf

In article <6376@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP (Robert Firth) writes:
|In article <5423@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (Nevin's evil twin brother :-))
writes:
||In article <561@etive.ed.ac.uk> db@lfcs.ed.ac.uk (Dave Berry) writes:

|||Would it be sensible to optimise the following code:

|||a := function ();
|||b := (complicated expression) * a;

|||to the equivalent of:

|||a:= function ();
|||if (a == 0)
|||  b := 0;
|||else
|||  (complicated expression) * a;


|So the cost is a single conditional branch not taken, and the benefit is
|presumably the cost of the "complicated expression".  Making a wild guess,
|the benefit will be at least 10x the cost, (the multiply alone accounts
|for half that), and substantially greater if the complicated expression
|includes things like two-dimensional array elements.

|So it is probably wrong to assert that A should be "much more likely to
|be 0 than not"; it should be good enough if A is zero 10% of the time.
|But that still seems an unlikely thing for a compiler to be able to
|deduce, so the optimisation is still probably unachievable without some
|clue.

I think that you are correct.  However, this brings up another question:
is this truly an optimization?  The way I (used to?) think about
optimization with respect to execution speed is that

	speed of optimized code >= speed of unoptimized code

for *all instantiations* of a given source statement.  Under this definition,
things like constant folding, common subexpression elimination, etc., can
all be considered optimizations.

The proposed optimization (explicit check for 0) does not meet my criteria,
however.  Assuming it can be determined that 'a' will be '0' at least 10%
of the time (and 'complicated expression' has no side effects, of course), and
that 10% is the point at which this optimization is worth making, the
*overall* execution speed of the program will be faster (also assuming that
this program is run often enough so that statistics actually applies to
it), but any given *instantiation* of the program might be slower.

Because of this, I (currently) consider this to be an algorithm design issue
and NOT a compiler optimization issue; ie, I *don't* want my compiler doing
this for me.
-- 
 _ __			NEVIN J. LIBER	..!att!ihlpb!nevin1	(312) 979-????
' )  )		 	 I got a new job and account but no office, *phone*, or
 /  / _ , __o  ____	 paycheck; is AT&T is trying to tell me something? :-)
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah