home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / compiler / 2023 < prev    next >
Encoding:
Internet Message Format  |  1992-12-13  |  2.7 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
  2. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  3. Newsgroups: comp.compilers
  4. Subject: Re: static estimation of conditional branches?
  5. Keywords: optimize, comment
  6. Message-ID: <92-12-055@comp.compilers>
  7. Date: 13 Dec 92 18:20:49 GMT
  8. Article-I.D.: comp.92-12-055
  9. References: <92-12-029@comp.compilers> <92-12-054@comp.compilers>
  10. Sender: compilers-sender@iecc.cambridge.ma.us
  11. Reply-To: hrubin@pop.stat.purdue.edu (Herman Rubin)
  12. Organization: Purdue University Statistics Department
  13. Lines: 40
  14. Approved: compilers@iecc.cambridge.ma.us
  15.  
  16.  
  17. idacrd!desj@uunet.UU.NET (David desJardins) writes:
  18. >... any programmer who is making a serious effort to write high-
  19. >performance code must know approximately how often each of the conditional
  20. >branches in critical sections is taken...
  21.  
  22. henry@zoo.toronto.edu (Henry Spencer) writes:
  23. >I agree with this statement, with one crucial substitution: for "must"
  24. >read "should", in the sense of "you should stay below the speed limit".
  25.  
  26. >When people first started implementing profilers and the like, they found
  27. >one striking result: human intuition about the locations of the hot spots
  28. >in a complex program was *consistently wrong*.  ...
  29.  
  30. There are many stiuations in which one KNOWS how often branches are taken,
  31. even if one does not know, for various reasons, how much time is spent in
  32. a given kind of operation.  When I post an algorithm for generating a kind
  33. of non-uniform random variable, if my reasoned estimates of how often each
  34. branch is done is off by more than roundoff, it is because the uniform
  35. input is not random.  If profiling finds anything different, either I have
  36. miscalculated or the input uniform random numbers do not have the
  37. properties they are supposed to have.
  38.  
  39. There are many other cases of this.  In numerical work, one might easily
  40. misguess on which major class of cases is most common, but one is not
  41. likely to be far off on what is happening locally.  Even someone fairly
  42. adept at numerical analysis will recognize what is known and what is not.
  43.  
  44. One should not design a language, or a compiler, so that a fool can use it
  45. "properly." In that case, it is quite likely that nobody can use it at a
  46. higher level than the fool.  Design it for the genius first, and then put
  47. in the cautions, etc., for the fool.
  48. -- 
  49. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  50. Phone: (317)494-6054 hrubin@snap.stat.purdue.edu (Internet, bitnet)  
  51. {purdue,pur-ee}!snap.stat!hrubin(UUCP)
  52. [I'd go the other way.  Geniuses are a lot more flexible than fools. -John]
  53. -- 
  54. Send compilers articles to compilers@iecc.cambridge.ma.us or
  55. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  56.