home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10444 < prev    next >
Encoding:
Internet Message Format  |  1992-11-07  |  2.2 KB
  1. Xref: sparky comp.arch:10444 comp.lang.misc:3516
  2. Newsgroups: comp.arch,comp.lang.misc
  3. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sdd.hp.com!cs.utexas.edu!sun-barr!ames!saimiri.primate.wisc.edu!usenet.coe.montana.edu!giac1.oscs.montana.edu!osycs
  4. From: osycs@giac1.oscs.montana.edu (Craig Spannring)
  5. Subject: Re: Hardware Support for Numeric Algorithms
  6. Message-ID: <1992Nov6.075459.13348@coe.montana.edu>
  7. Keywords: n
  8. Sender: usenet@coe.montana.edu (USENET News System)
  9. Organization: Geographic Information & Analysis Center Montana State University
  10. References: <1992Oct23.004313.29196@ntuix.ntu.ac.sg> <1992Oct29.153514.22927@yrloc.ipsa.reuter.COM> <1992Nov5.202412.7266@linus.mitre.org>
  11. Date: Fri, 6 Nov 1992 07:54:59 GMT
  12. Lines: 30
  13.  
  14.  
  15. In article <1992Nov5.202412.7266@linus.mitre.org> bs@gauss.mitre.org (Robert D. Silverman) writes:
  16. >You've probably never done any large scale computing.
  17. >
  18. >I measure the run time of my algorithms in MIPS-YEARS.  A MIPS-YEAR
  19. >is a 1 MIPS machine running for 1 year, or approximately 3.1 x 10^13
  20. >instructions.  Jobs that take several hundred MIPS-YEARS are not uncommon.
  21.  
  22. Large scale computing demands that you to avoid the unreadable
  23. micro-optimizations that Herman is suggesting.  If one of your little
  24. attempts at optimizing the code ends up producing incorrect results
  25. then you've just wasted months of research time.  Meanwhile your
  26. colleagues that have programs producing correct results are getting
  27. published and getting grants.  How much research and computing time are
  28. you wasting with buggy programs?
  29.  
  30. The second problem with these 'optimizations' is that they aren't.
  31. Herman seems to be most concerned with saving a few clock cycles per
  32. iteration.  The only significant performance gains will be found be
  33. using an algorithm that uses fewer iterations.  Example-  Even a highly
  34. optimized bubble sort will run slower than an unoptimized quick sort
  35. for the large data sets you are refering to.
  36.  
  37. Get a clue.
  38.  
  39. -- 
  40. =========================================================================
  41.  Six of one, 110 (base 2) of | Craig Spannring --- (406) 994-6128
  42.  another.                    | osycs.giac1.oscs.montana.edu
  43.  ----------------------------+ Geographic Information & Analysis Center
  44.