home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10764 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  3.2 KB
  1. Xref: sparky comp.arch:10764 comp.lang.misc:3704
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!wupost!usc!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  3. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
  6. Date: 13 Nov 92 14:40:57
  7. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  8.     Perceptive)
  9. Lines: 63
  10. Message-ID: <TMB.92Nov13144057@arolla.idiap.ch>
  11. References: <1992Oct29.153514.22927@yrloc.ipsa.reuter.COM>
  12.     <1992Nov5.202412.7266@linus.mitre.org>
  13.     <1992Nov10.153705.27804@yrloc.ipsa.reuter.COM>
  14.     <1992Nov12.131856.12605@linus.mitre.org>
  15. Reply-To: tmb@idiap.ch
  16. NNTP-Posting-Host: arolla.idiap.ch
  17. In-reply-to: bs@gauss.mitre.org's message of Thu, 12 Nov 1992 13:18:56 GMT
  18.  
  19. bs@gauss.mitre.org writes:
  20. > rbe@yrloc.ipsa.reuter.com writes:
  21. > > Optimization before design is usually a bad idea. 
  22. >
  23. > Spouting aphorisms adds little to this discussion. Especially since you
  24. > are assuming facts not in evidence. (i.e. you are assuming that the
  25. > optimization came before the design).
  26.  
  27. What Rubin codes in the privacy of his own VAX is his own business.
  28.  
  29. But he is trying to use his code as an example to convince the rest of
  30. us that we should pay for our computer manufacturers to incorporate
  31. "get bit from bitsream" and "generate exponential rv" instructions,
  32. and to add all sorts of bells and whistles to our programming
  33. language. If he wants to make such an argument convincingly, he has
  34. to write clear, readable code.
  35.  
  36. In fact anybody who wants to make such an argument to add hairy
  37. features to a programming language in order to achieve higher
  38. performance has to do more than just present a piece of code. He
  39. really should present:
  40.  
  41.  * a straightforward, readable, clear implementation of the
  42.    piece of code containing the alleged bottleneck so that
  43.    people know what the problem is
  44.  
  45.  * a realistic (or at least believable) driver that uses the code
  46.  
  47.  * actual profiling information using the driver that demonstrates
  48.    that the alleged bottleneck actually uses up a significant amount
  49.    of time
  50.  
  51.  * some readable discussion, analysis, and evaluation of the results;
  52.  
  53.    in the case of hardware features, this should include:
  54.  
  55.    + a discussion of several known architectures, cycle times, cost of
  56.      additional hardware/VLSI real estate, etc.;
  57.  
  58.    in the case of software features, this should include:
  59.  
  60.    + a discussion of why optimizers can't currently handle this case,
  61.  
  62.    + how the feature interacts with the optimizer--does it perhaps
  63.      inhibit other optimizations?,
  64.  
  65.    + why other language constructs can't handle it,
  66.  
  67.    + statistics (or at least a believable argument) from actual
  68.      programs that show that the feature is used frequently enough
  69.      that it warrants incorporation into the language (occasional
  70.      hacks can be put into assembly language),
  71.  
  72.    + considerations of syntax, considerations of scoping and
  73.      referential transparency, etc.
  74.  
  75. Such a discussion serves to try to convince others not only that the
  76. feature is worthwhile to consider, but also that the proponent has
  77. actually the knowledge and experience to make an informed proposal.
  78.  
  79. Anything else is just handwaving and doesn't convince me.
  80.  
  81.                     Thomas.
  82.