home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / programm / 3543 < prev    next >
Encoding:
Text File  |  1993-01-21  |  2.9 KB  |  63 lines
  1. Newsgroups: comp.programming
  2. Path: sparky!uunet!gatech!hubcap!mjs
  3. From: mjs@hubcap.clemson.edu (M. J. Saltzman)
  4. Subject: Re: C specific editor (was Re: C/C++ Speed)
  5. Message-ID: <1993Jan21.193158.3853@hubcap.clemson.edu>
  6. Organization: Clemson University, Clemson SC
  7. References: <1993Jan17.041622.5602@thunder.mcrcim.mcgill.edu> <47740001@hplvec.LVLD.HP.COM>
  8. Date: Thu, 21 Jan 1993 19:31:58 GMT
  9. Lines: 52
  10.  
  11. In article <47740001@hplvec.LVLD.HP.COM> elw@hplvec.LVLD.HP.COM (Eddie Williamson) writes:
  12. >----------
  13. >>>  In article <1993Jan15.160435.19703@acuson.com>,
  14. >>>  miklg@acuson.com (Michael Goldman ) writes:
  15. >
  16. >>> The whole discussion of speed is limited to inexperienced people.  In
  17. >>> real world applications, the hardware will double your speed in the
  18. >>> time it takes to write the application.
  19. >
  20. >----------
  21. >> hplvec:comp.programming 
  22. >> kurt@tc.fluke.COM (Kurt Guntheroth) 
  23. >> 9:54 am  Jan 18, 1993 /
  24. >>
  25. >> The net result is that in the *real* real world, efficiency is *always*
  26. >> important.  In the synthetic real world imagined by acedemics, you can wave
  27. >> your magic wand and say "just buy enough hardware to make it fast", but when
  28. >> you are spending your own money, or money that comes out of your profit
  29. >> sharing bonus, or from somebody other than nameless taxpayers, you have to
  30. >> buy what you can afford, and live with what you buy.  
  31. >----------
  32. >I agree! (with the second paragraph)
  33. >Most real world customers can't affort to go out and buy the latest
  34. >hardware every time they buy new application software. They live with
  35. >what they already have. Don't make excuses for being lazy. Design your
  36. >software from the beginning with efficiency in mind. You'll end up
  37.  
  38. As an academic and a government employee, I'd just like to point out
  39. that we don't get to spend nameless taxpayers' money just to go out
  40. and buy new hardware every time we buy new software, any more than
  41. anyone else.  In fact, we often don't even get to go out and buy the
  42. software!  We also buy what we can afford and live with what we buy,
  43. and we often live longer with less than many in the so-called real
  44. world.
  45.  
  46. Algorithm designers don't abstract the constant factor away because
  47. they think you can always make it up by buying new hardware--they do
  48. it because they want to make a hardware-independent comparison of
  49. algorithms.  On the other hand, it usually really is the case that
  50. better asymptotic performance beats a constant-factor reduction (if
  51. the constant isn't ridiculous to begin with), especially when it's
  52. important (when problems get large).
  53.  
  54. If it's important to solve moderate-sized problems quickly, then the
  55. constant *is* important.  But it's also often true that most of the 
  56. constant factor can be had with attention to only a small portion of
  57. the code.  You can almost always pick this up after the implementation 
  58. is complete with careful profiling.
  59. -- 
  60.         Matthew Saltzman
  61.         Clemson University Math Sciences
  62.         mjs@clemson.edu
  63.