home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10497 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  5.0 KB
  1. Xref: sparky comp.arch:10497 comp.lang.misc:3539
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sunic!psinntp!psinntp!dg-rtp!sheol!throopw
  3. From: throopw@sheol.UUCP (Wayne Throop)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Re: Hardware Support for Numeric Algorithms
  6. Summary: make it right and THEN make it faster
  7. Message-ID: <721104899@sheol.UUCP>
  8. Date: 07 Nov 92 00:12:40 GMT
  9. References: <1992Nov5.202412.7266@linus.mitre.org> <1992Nov5.203759.8030@linus.mitre.org>
  10. Lines: 87
  11.  
  12. ( The topic seems to have drifted quite far from the "Subject:" 
  13.   line, but I'll leave it alone. )
  14.  
  15. : From: bs@gauss.mitre.org (Robert D. Silverman)
  16. : Message-ID: <1992Nov5.202412.7266@linus.mitre.org>
  17. : Needless to say, there are people who have to worry about speed FIRST,
  18. : and that other considerations are (almost) irrelevent.
  19.  
  20. : From: bs@gauss.mitre.org (Robert D. Silverman)
  21. : Message-ID: <1992Nov5.203759.8030@linus.mitre.org>
  22. : Dr. Rubin's main rule is:
  23. :       "The code should run as fast as possible"
  24. : For him, all other considerations are secondary. Who are you to tell
  25. : him what his priorities should be?
  26.  
  27. Ah, Robert seems to be saying that Dr. Rubin is a member of that large
  28. class of people for whom it is very very important to get the wrong
  29. answer as soon as possible.  But wait.... if "The code should run as
  30. fast as possible" and "all other considerations are secondary", why
  31. doesn't he just run the null istream?
  32.  
  33. Since Dr. Rubin *doesn't* suggest running the null istream, I conclude
  34. that the "(almost) irrelevant" above contains a very, very large point
  35. swept under the rug.  It is of *primary* importance that the code be
  36. correct.
  37.  
  38. Therefore I claim that the nits people have been picking have not been
  39. empty nits.  The suggestions about maintanability and readability are
  40. not wrong-headed.  They speak to the primary goal of the code: to get
  41. the right answer.
  42.  
  43. And I am always very VERY skeptical that it is *ever* important to
  44. "worry about speed FIRST" for code that does not constitute a
  45. bottleneck.  Which, for any nontrivial system, is fairly sure in
  46. practice to be in excess of 80% of the code.  And even for those
  47. segments of code that need excruciating attention to speed, the
  48. developer had better worry about *correct* *results* FIRST.
  49.  
  50. : There are times when readability, portability, and ease of maintenance
  51. : are of primary importance. There are times when they don't matter at
  52. : all. Stop pretending that they are the end-all of good coding.
  53.  
  54. I agree that readability, portability and maintainability can be
  55. reasonably traded off against required speed.  But since readability 
  56. and maintainability are so intimately related to getting the code to be
  57. correct and then keeping the code correct, I find it impossible to
  58. agree that there are *ever* times when these two "don't matter at all".
  59.  
  60. Now, with all that said, I must also say that I have a great deal of
  61. sympathy with (what I take to be) Dr. Rubin's general position.
  62. Optimizing cricical code in high-level languages usually feels like
  63. trying to pick a lock while wearing welding gloves.  It would be very
  64. nice if there were a way to just strip off those gloves and get down
  65. and dirty with the generated istream.
  66.  
  67. But when the lock you are trying to pick is red-hot, you'll just burn
  68. your hands that way.  And further, such hands-on features are
  69. inherrently unportable, and hence are not standardized because they
  70. *can't* be standardized.  You are wearing the welding gloves in the
  71. first place because you're working with hot material, and the gloves
  72. are how you deal with that. (That is, you are using a high-level
  73. language because you are working with very complex and detailed
  74. problems, and the high-level language is a standard way of dealing with
  75. complexity.)  You can't expect glove manufacturers to put Yale or Slage
  76. lockpicking features into every glove they sell, since not every welder
  77. needs to pick locks, and even those that pick locks don't *all* work
  78. on Yale or Slage locks.  It isn't economically feasible.
  79.  
  80. But don't get the idea that I think that high-level languages shouldn't
  81. incorporate graceful fallback to low-level access to the underlying
  82. implementation.  Just as I pine for smoothly integrated bit-level
  83. access in source level debuggers, and often don't get it, I wish
  84. language systems more often allowed better control over the generated
  85. code for those cases where I'm sweating away in my welding gloves
  86. poking at that annoying lock.  I just have empathy for how hard it
  87. is to do such things right, and how unfair it would be for me to blame
  88. the manufacturer of the welding gloves I'm using just because they
  89. won't "do what I want" instead of what they were designed for within
  90. the constraints of their resources and market.
  91.  
  92.  
  93. Let me summarize it all in this way.  I think that television is
  94. a vast wasteland.  But rather than repeatedly complaining that network
  95. programmers don't program to suit me, I go and read books, play with
  96. netnews, rent video tapes, and go to movies.
  97. --
  98. Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
  99.