home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / arch / 9370 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  4.3 KB
  1. Xref: sparky comp.arch:9370 comp.lang.misc:3031
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  3. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
  6. Message-ID: <BuFK3y.3H5@mentor.cc.purdue.edu>
  7. Date: 11 Sep 92 20:11:57 GMT
  8. References: <1992Sep4.151001.9886@sei.cmu.edu> <Bu5qD3.GAM@mentor.cc.purdue.edu> <1992Sep11.184744.19329@CS.ORST.EDU>
  9. Sender: news@mentor.cc.purdue.edu (USENET News)
  10. Organization: Purdue University Statistics Department
  11. Lines: 73
  12.  
  13. In article <1992Sep11.184744.19329@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
  14. >In article <Bu5qD3.GAM@mentor.cc.purdue.edu>
  15. >hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  16. >>And then the hardware designers, being told that something is useless, drop
  17. >>it from the instruction set?
  18.  
  19. >You misunderstand what has happened in the industry.  The hardware designers
  20. >were told that something was rarely used, and therefore was not cost
  21. >effective.  As good engineers, they dropped the feature.
  22.  
  23. >>Designing flexibility in both hardware and software is not that expensive;
  24. >>putting in something left out may be.
  25.  
  26. >My experience is just the opposite.  Designing flexibility in either hardware
  27. >or software is very expensive.  Given the time to program a simple utility
  28. >with one option versus one with twenty supports this claim.  The time to build
  29. >an shifter of constant shift versus one of variable shift also supports this
  30. >claim.  I invite you to provide _evidence_ in support of your claim.
  31.  
  32. >I grant you, putting something in later will be expensive.
  33.  
  34. >>A simple example is that of square root.  The cost of putting in square root
  35. >>on any machine which has "classical" division hardware is essentially zero
  36. >>at the design and construction stage, but an algorithm to do it is otherwise
  37. >>is necessarily slow and costly.
  38.  
  39. >Only costly when making simplistic comparisons.  If the lack of square root
  40. >hardware increases my run time from 10 seconds to 10.0001 seconds (which is
  41. >probably realistic for many if not most program runs), it is _not_ costly.
  42.  
  43. If the increase is that small, not even very many divisions are likely to 
  44. be done.  If one is only interested in the characteristic roots and a 
  45. few characteristic vectors, the most commonly used method at this time,
  46. the QR algorithm, would spend most of its time in computing square roots.
  47. At best, it spends a fair amount in that operation.
  48.  
  49. >>Bit vectors do not necessarily start on a word, or even a byte, boundary,
  50.  
  51. >Yes, but if only one in a million don't, supporting non-aligned bit vectors
  52. >probably isn't cost effective.
  53.  
  54. "Natural" programming on the CYBER 205 would have at least an appreciable
  55. portion of bit vectors unaligned, if not most.  Now there are ways of 
  56. reprogramming to avoid some of this, but very definitely not all.  This
  57. programming requires more than a knowledge of HLLs.
  58.  
  59. >>and again, it is easier to deal with the problem at hardware design time
  60. >>rather than in software.
  61.  
  62. >This claim is strongly supported by the wide abundance of hardware-implemented
  63. >compilers and spreadsheet packages.  :-)  My experience indicates that the
  64. >cost to deliver a working solution to _almost_any_ problem is cheaper in
  65. >software than hardware.  Consider the cost of building a working multiplier
  66. >versus the cost of writing an iterative adding subroutine.  I invite you to
  67. >provide _evidence_ that your claim is true.
  68.  
  69. But the building of the multiplier is done once, and the adding subroutine is
  70. run billions of times.  Ask a designer how much more it would cost to put in
  71. fixed multiplication with the accuracy of floating at the time it was being
  72. built.  Every floating point unit essentially contains a fixed point unit
  73. inaccessible to the user.
  74.  
  75. >What you meant to say is "its easier for me if the hardware designers gave me
  76. >exactly what I wanted".
  77.  
  78. It is also easier for the number theorists, signal processing people, and
  79. anyone who does not rely on cheap inefficient packages, which frequently are
  80. so bad that the roundoff, undetected, gives highly erroneous results.
  81. -- 
  82. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  83. Phone: (317)494-6054
  84. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  85. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  86.