Re: static estimation of conditional branches?

hrubin@pop.stat.purdue.edu (Herman Rubin)
Sun, 13 Dec 1992 18:20:49 GMT

          From comp.compilers

Related articles
[8 earlier articles]
Re: static estimation of conditional branches? henry@zoo.toronto.edu (1992-12-11)
Re: static estimation of conditional branches? idacrd!desj@uunet.UU.NET (1992-12-12)
Re: static estimation of conditional branches? jfisher@hplabsz.hpl.hp.com (1992-12-11)
Re: static estimation of conditional branches? chased@rbbb.Eng.Sun.COM (1992-12-12)
Re: static estimation of conditional branches? glew@pdx007.intel.com (1992-12-12)
Re: static estimation of conditional branches? henry@zoo.toronto.edu (1992-12-13)
Re: static estimation of conditional branches? hrubin@pop.stat.purdue.edu (1992-12-13)
Re: static estimation of conditional branches? drw@euclid.mit.edu (1992-12-14)
Re: static estimation of conditional branches? idacrd!desj@uunet.UU.NET (1992-12-14)
Re: static estimation of conditional branches? iwm@doc.ic.ac.uk (1992-12-14)
Re: static estimation of conditional branches? pcg@aber.ac.uk (1992-12-15)
| List of all articles for this month |

Newsgroups: comp.compilers
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Organization: Purdue University Statistics Department
Date: Sun, 13 Dec 1992 18:20:49 GMT
References: 92-12-029 92-12-054
Keywords: optimize, comment



idacrd!desj@uunet.UU.NET (David desJardins) writes:
>... any programmer who is making a serious effort to write high-
>performance code must know approximately how often each of the conditional
>branches in critical sections is taken...


henry@zoo.toronto.edu (Henry Spencer) writes:
>I agree with this statement, with one crucial substitution: for "must"
>read "should", in the sense of "you should stay below the speed limit".


>When people first started implementing profilers and the like, they found
>one striking result: human intuition about the locations of the hot spots
>in a complex program was *consistently wrong*. ...


There are many stiuations in which one KNOWS how often branches are taken,
even if one does not know, for various reasons, how much time is spent in
a given kind of operation. When I post an algorithm for generating a kind
of non-uniform random variable, if my reasoned estimates of how often each
branch is done is off by more than roundoff, it is because the uniform
input is not random. If profiling finds anything different, either I have
miscalculated or the input uniform random numbers do not have the
properties they are supposed to have.


There are many other cases of this. In numerical work, one might easily
misguess on which major class of cases is most common, but one is not
likely to be far off on what is happening locally. Even someone fairly
adept at numerical analysis will recognize what is known and what is not.


One should not design a language, or a compiler, so that a fool can use it
"properly." In that case, it is quite likely that nobody can use it at a
higher level than the fool. Design it for the genius first, and then put
in the cautions, etc., for the fool.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054 hrubin@snap.stat.purdue.edu (Internet, bitnet)
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
[I'd go the other way. Geniuses are a lot more flexible than fools. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.