home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / programm / 15995 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  1.9 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!agate!apple!decwrl!contessa!mwm
  2. From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
  3. Subject: Re: New hardware reference guide?
  4. Newsgroups: comp.sys.amiga.programmer
  5. Distribution: world
  6. References: <1992Nov12.215020.20036@ultb.isc.rit.edu> <1992Nov16.134153.6356@ifi.uio.no>
  7. X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
  8. Keywords: 
  9. Summary: 
  10. Message-ID: <mwm.2oo3@contessa.palo-alto.ca.us>
  11. Date: 17 Nov 92 14:01:11 PST
  12. Organization: Missionaria Phonibalonica
  13. Lines: 30
  14.  
  15. In <1992Nov16.134153.6356@ifi.uio.no>, olavka@ifi.uio.no (Olav Lur}s Kalgraf) wrote:
  16. > > We need blazing speed, not necessarily optimized assembly.  Two different
  17. > > things.
  18. > > 
  19. > Different, true. But also very closely connected, optimized assembly
  20. > means blazing speed. 
  21.  
  22. Not in the sense people usually mean when they say "optimized
  23. assembly"; that of someone carefully scrutinizing code to squeeze the
  24. last cycle out of it. Optimizing the wrong algorithm (the vector math
  25. example mentioned earlier comes to mind) means you get fast code, but
  26. a slow program.
  27.  
  28. In the more general sense of optimizing the entire program - looking
  29. at large collections of sample data, choosing an algorithm that fits
  30. it well, looking at the sample again and seeing where most of the time
  31. is going, making that faster, etc - then assembly is sort of moot.
  32. It's "optimized X means blazing speed", where X is pretty much
  33. anything that isn't interpreted, and avoids provoking things with lots
  34. of overhead. You can even do it with LISP, if you know how. 
  35.  
  36. That said, it's generally true that the closer you are to the
  37. hardware, the easier it is to insure that you're not provoking
  38. something with lots of overhead. A bad compiler could translate to
  39. "lots of overhead". Even with a good compiler, there are gotchas. In
  40. C, you have to worry about accidently invoking a support routine to do
  41. your math; in LISP, you have to worry about using any routine that
  42. does a cons.
  43.  
  44.     <mike
  45.