home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / misc / 3834 < prev    next >
Encoding:
Internet Message Format  |  1992-11-22  |  7.0 KB
  1. Path: sparky!uunet!psinntp!dg-rtp!sheol!throopw
  2. From: throopw@sheol.UUCP (Wayne Throop)
  3. Newsgroups: comp.lang.misc
  4. Subject: Software Support for Numeric Algorithms
  5. Message-ID: <722469565@sheol.UUCP>
  6. Date: 22 Nov 92 19:52:47 GMT
  7. References: <722061187@sheol.UUCP> <1efh6vINNm6c@network.ucsd.edu> <722228704@sheol.UUCP> <By2MH8.JFB@mentor.cc.purdue.edu>
  8. Lines: 127
  9.  
  10. : From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
  11. : Message-ID: <By2MH8.JFB@mentor.cc.purdue.edu>
  12. : I can get gcc on some machines, [..but..] it cannot be used for program
  13. : design for more than one machine, which is something I am supposed to be
  14. : involved in.  This is a major reason for asking for a good macro
  15. : translator, to isolate the dependent problems from the independent ones
  16. : and still be able to communicate. 
  17.  
  18. So it's supposed to be easier to invent an entire language from scratch
  19. and target it to N machines, all producing good code, than to port an
  20. existing compiler to M-less-than-N machines?  An interesting perspective,
  21. one that has lead many people to reinvent the travois rather than use
  22. steel-belted radials (kevlar belts being unavailable in their size). 
  23.  
  24. : I can communicate the algorithm to a mathematician using any one of those
  25. : machines in such a way that a language hacker could come up with good
  26. : code in consultation.
  27.  
  28. Yes indeed.  As I've been saying all along, Herman Rubin's problems are
  29. primarily economic ones.  He hasn't allocated enough money (or other
  30. incentives) to pay "language hackers" to work on his problems.  If
  31. anything, he's been providing social DISincentives. 
  32.  
  33. :: So as near as I can see, solutions to the problems Herman Rubin
  34. :: complains about are out there, and available for use now.  Herman Rubin
  35. :: simply refuses to use them until they are customized for his needs to
  36. :: an uneconomical extent.
  37. : For an individual machine, they have always been there.  Programming in
  38. : obfuscated assembler languages can do anything.
  39.  
  40. Which, of course, misses the point of what I said on two accounts.
  41. First, I was not talking about "obfuscated assembler language".  I was
  42. talking about tools for building high-level languages.  And second
  43. (and most silly), it totally overlooks the *main* point, which was
  44. the economic one.
  45.  
  46. :: The bottom line: Herman Rubin is attributing to malice and stupidity 
  47. :: what is adequately explained by simple economics.
  48. : I have generally charged inadvertence rather than malice.  However, I do
  49. : charge anyone who leaves out something "because it can be misused" with
  50. : malice.  I do charge anyone who says that "these tools are adequate to do
  51. : a good quick job" with malice if it is not the case.
  52.  
  53. The "because it can be misused" is a straw man.  *Some* people claim
  54. that "because it *tends*to*be* misused" as a reason to omit a feature,
  55. but this is not really close to Herman Rubin's version.  And second,
  56. most people I've seen respond to Herman Rubin's postings have NOT
  57. held anything like this position.  Certainly, *I* do not.
  58.  
  59. The "these tools are adequate to do a quick job" being malice if the
  60. "adequate" is false is blatant overstatement.  It may simply be a
  61. mistake, or a misunderstanding of what "job" is involved.  Jumping to
  62. the conclusion of "malice" is unwarranted, by a wide margin. 
  63.  
  64. : The situation is similar to what has happened to our educational system;
  65. : we have set up procedures so that more harm than good has been done.  In
  66. : education, teaching rote without understanding destroys minds and makes
  67. : it difficult to acquire the understanding later; in hardware and software,
  68. : restricting the possibilities makes subsequent flexibility much harder.
  69.  
  70. "I would agree with you if you were correct." In schools, there is a
  71. demonstrated "dumbing down" of vocabulary and such, year by year, and it
  72. is pretty plausibly linked to the misguided practice of removing
  73. exposure to "above average" topics and vocabulary (where "average" is
  74. based on last year's acheivement).  But in computer languages, the
  75. notations are NOT getting less and less expressive as time goes on. 
  76. Consider the standardized versions of Fortran over the years.  Or the
  77. shift from C to C++.  Or Pascal to Ada.  Or the shift as various Lisp
  78. dialects became Common Lisp. 
  79.  
  80. The general trend is for languages to become more and more expressive
  81. over time, and for optimizations routinely done to be more and
  82. more advanced, contrary to Herman Rubin's analogy above.
  83.  
  84. Note well, I'm not saying here that "most current languages solve Herman
  85. Rubin's problems" or anything close to that.  Simply that Herman Rubin's
  86. claim that languages are "dumbing down" over time is not consistent with
  87. the facts of the matter. 
  88.  
  89. :: Yes, this  [.. the interface to code generation ..]
  90. :: is the most central problem, which Jim Giles mentioned also.
  91. :: Some method is needed which will specify the generated code, and yet
  92. :: will fit in with the optimizations and register allocations and so on
  93. :: which are already in place.  Jim says this "isn't too difficult", but 
  94. :: I think it is the single most difficult part.  I've seen several
  95. :: solutions, each with some advantages over the others.
  96.  
  97. : THIS is one aspect of the problem; the attempt to get a detailed complete
  98. : package, instead of putting partial solutions together; the attempt to
  99. : take the programmer out of an interactive optimization procedure with the
  100. : compiler; the failure to realize that the present so-called optimizations
  101. : and register allocations are often bad; etc.
  102.  
  103. Herman Rubin's complaints here simply do not follow from what I said.  
  104. I said the problem was hard, and no single solution I was aware of was
  105. clearly better than others.  It does NOT follow that I advocate doing
  106. nothing.  I said that inserting explicit instructions in the istream
  107. requires integration with automated optimizations to be effective.  It
  108. does NOT follow that I want to "take the programmer out of an
  109. interactive optomization procedure".  I implied that the baby of current
  110. automated optimizations should not be thrown out with the bathwater of
  111. increased programmer control.  This does NOT imply that I think current
  112. "so-called optimizations" are all perfect, or even good. 
  113.  
  114. Herman Rubin is simply putting up a straw man here.  Certainly,
  115. I don't acknowledge the effigy as a good likeness of ME.
  116.  
  117. :: [...] if a programmer comes up with something unforseen by the
  118. :: optimizer, there's no simple way to give a hint about it.
  119. : So put in simple ways to give hints, instead of saying that no hints
  120. : can be given.  
  121.  
  122. Another non-sequitur.  I never said that "no hints can be given".
  123.  
  124. : The difference is not the last 1% of speed, but often
  125. : 50% of the running time or more.
  126.  
  127. Herman really has a case where "hints to the optimizer" about single
  128. instructions can yield 50% of the running time of a whole system?  Wow. 
  129. The most I've ever seen was 5 to 10 percent of time in a system spent on
  130. a single instruction in an early version of a hash routine. 
  131.  
  132. Of course, the point is unaffected by this...  the point is, if istream
  133. changes of that granularity affect performance that needs to be had,
  134. there's no alternative to specifying the istream by hand. 
  135. --
  136. Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
  137.