home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10467 < prev    next >
Encoding:
Internet Message Format  |  1992-11-07  |  3.1 KB
  1. Xref: sparky comp.arch:10467 comp.lang.misc:3527
  2. Path: sparky!uunet!snorkelwacker.mit.edu!ai-lab!arolla!tmb
  3. From: tmb@arollaidiap.ch (Thomas M. Breuel)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Re: Hardware Support for Numeric Algorithms
  6. Date: 6 Nov 1992 17:18:12 GMT
  7. Organization: MIT Artificial Intelligence Lab
  8. Lines: 50
  9. Distribution: world
  10. Message-ID: <1de9ckINNfj7@life.ai.mit.edu>
  11. References: <BwJ4uz.1rA@rice.edu> <1992Oct23.004313.29196@ntuix.ntu.ac.sg> <1992Oct29.153514.22927@yrloc.ipsa.reuter.COM> <1992Nov5.202412.7266@linus.mitre.org>
  12. Reply-To: tmb@ai.mit.edu
  13. NNTP-Posting-Host: arolla.idiap.ch
  14.  
  15. In article <1992Nov5.202412.7266@linus.mitre.org>, bs@gauss.mitre.org (Robert D. Silverman) writes:
  16. |> In article <1992Oct29.153514.22927@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
  17. |> :
  18. |> :I write programs for correctness and maintainability first, THEN worry
  19. |> :about little details such as performance. If you create something that's
  20. |>  
  21. |> You've probably never done any large scale computing.
  22. |> 
  23. |> I measure the run time of my algorithms in MIPS-YEARS.  A MIPS-YEAR
  24. |> is a 1 MIPS machine running for 1 year, or approximately 3.1 x 10^13
  25. |> instructions.  Jobs that take several hundred MIPS-YEARS are not uncommon.
  26. |> 
  27. |> Needless to say, there are people who have to worry about speed FIRST,
  28. |> and that other considerations are (almost) irrelevent.
  29. |> 
  30. |> I wish you people would stop insulting Herman simply because his requirements
  31. |> leads to code that is different from your petty and self-righteous 
  32. |> pre-conceived notions about coding style.
  33. |> 
  34. |> :wrong, or that has to be scrapped in a year because nobody can understand
  35. |> :it, who cares how fast it runs?
  36. |>  
  37. |> Not everyone writes commercial code, or code for customers. Maybe it's
  38. |> a research project that will end in a year. Stop being so provincial.
  39.  
  40. I do write and use long-running programs (weeks, months) that use
  41. multiple workstations extensively in my work.
  42.  
  43. For such programs, I find that correctness and maintainability are of
  44. paramount importance.  Efficiency, on the other hand, is of much
  45. less importance.  If I run my program once for 9 weeks, I'm going to be
  46. much better off than if I speed it up by 30% but have to run it twice
  47. (for a total of 12 weeks) because I introduced some error.
  48.  
  49. I think the idea that scientific programmers have to squeeze every last
  50. cycle out of their machines is a myth passed on from generation to
  51. generation and is out of touch with the modern economic realities of
  52. programming. The only people who have to squeeze every last cycle out
  53. of their programs are real-time programmers and software/hardware
  54. vendors who are concerned with looking good on benchmarks.
  55.  
  56. I wouldn't care much if you make yourself unhappy by writing messy,
  57. unmaintainable, unportable, "optimized" code that will crawl along 
  58. miserably once the next generation of hardware comes along. However,
  59. sadly, users like you are the most vocal when it comes to incorporating
  60. unnecessary and costly "efficiency" features into languages, operating
  61. systems, and hardware, and the rest of us have to pay the price
  62. and suffer the consequences.
  63.  
  64.                     Thomas.
  65.