home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / compiler / 2017 < prev    next >
Encoding:
Text File  |  1992-12-12  |  2.3 KB  |  50 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!world!iecc!compilers-sender
  3. From: idacrd!desj@uunet.UU.NET (David desJardins)
  4. Subject: Re: static estimation of conditional branches?
  5. Reply-To: idacrd!desj@uunet.UU.NET (David desJardins)
  6. Organization: IDA Center for Communications Research, Princeton
  7. Date: Sat, 12 Dec 1992 04:37:35 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-12-049@comp.compilers>
  10. Keywords: optimize
  11. References: <92-12-029@comp.compilers> <92-12-047@comp.compilers>
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 35
  14.  
  15. The moderator wrote:
  16. > [As I recall, Fortran II dropped FREQUENCY because it was infrequently
  17. > used and made little difference.  I've heard that it may even have been
  18. > implemented backwards and nobody noticed. -John]
  19.  
  20. Henry Spencer <henry@zoo.toronto.edu> writes:
  21. > The other problem that occurs with such facilities is that programmer
  22. > intuition is notoriously unreliable about such things.
  23.  
  24. I don't understand this statement in this context in this context.  I know
  25. it's fashionable in this group to claim that compilers are supergeniuses
  26. and humans are idiots.  This might even sometimes be the case for examples
  27. like, "Should the variable FOO be held in a register?"  After all, a
  28. typical programmer would not know enough about the compiler internals and
  29. machine architecture to know all of the tradeoffs involved in this
  30. decision.
  31.  
  32. But any programmer who is making a serious effort to write high-
  33. performance code must know approximately how often each of the conditional
  34. branches in critical sections is taken.  That's not a matter of
  35. "intuition."  It's a question of understanding what the code is doing: an
  36. understanding which is fundamental to optimization.
  37.  
  38. And we are just talking about communicating those facts from the
  39. programmer to the compiler, with no judgments about their implications
  40. attached.  It's up to the compiler to draw the appropriate conclusions, if
  41. any.  I don't see how this can be "unreliable."
  42.  
  43. Of course, I too endorse the feedback of profiler information as a more
  44. convenient (to the user) way to achieve similar results.
  45.  
  46.                                         David desJardins
  47. -- 
  48. Send compilers articles to compilers@iecc.cambridge.ma.us or
  49. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  50.