Path: utzoo!utgpu!watserv1!watmath!att!rutgers!usc!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew
From: aglew@oberon.crhc.uiuc.edu (Andy Glew)
Newsgroups: comp.arch
Subject: Re: Hot Spots
Message-ID: <AGLEW.90Jul15165118@oberon.crhc.uiuc.edu>
Date: 15 Jul 90 23:51:18 GMT
References: <40052@mips.mips.COM> <628@dg.dg.com> <64045@sgi.sgi.com>
	<1990Jul13.173331.22918@zoo.toronto.edu> <16883@dime.cs.umass.edu>
	<AGLEW.90Jul13203247@dwarfs.crhc.uiuc.edu>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois, Computer Systems Group
Lines: 16
In-Reply-To: aglew@dwarfs.crhc.uiuc.edu's message of 13 Jul 90 20:32:47

Just it case it isn't obvious, I don't object to thresholding, only to
thresholding too early.
    A correspondent mentioned using thresholding as a criterion for
inclusion of features in an instruction set architecture. No problem.
My problem is, if two features F1 and F2 must work together, and if
when implemented together you get performance improvement P(F1,F2),
but if implemented separately you get only performance improvements
P(F1) and P(F2), such that P(F1)+P(F2)<<P(F1,F2), is with applying the
threshold rule to reject both F1 and F2, because P(F1)<T and P(F2)<T,
even though P(F1,F2)>2*T.
    Ie. my problem is with applying the threshold criterion such that
you burn down the trees because no single tree will provide shelter,
even though the forest would keep you nice and dry.

--
Andy Glew, aglew@uiuc.edu