home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / next / misc / 22235 < prev    next >
Encoding:
Internet Message Format  |  1992-11-22  |  1.5 KB
  1. Xref: sparky comp.sys.next.misc:22235 comp.sys.next.hardware:2786
  2. Newsgroups: comp.sys.next.misc,comp.sys.next.hardware
  3. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!data.nas.nasa.gov!data!gumby
  4. From: gumby@Cygnus.COM (David V. Henkel-Wallace)
  5. Subject: Specialized hardware ain't what it's cracked up to be (was: New RISC chip  / IMS 3250)
  6. In-Reply-To: bruce@pages.com's message of 17 Nov 92 20:59:59 GMT
  7. References: <1992Nov15.192329.324@pages.com> <1992Nov17.205959.8187@pages.com>
  8. Sender: news@nas.nasa.gov (News Administrator)
  9. Organization: Cygnus Support, Palo Alto, California
  10. Date: 23 Nov 92 02:17:02
  11. Message-ID: <GUMBY.92Nov23021702@Cygnus.COM>
  12. Lines: 18
  13.  
  14.    Date: 17 Nov 92 20:59:59 GMT
  15.    From: bruce@pages.com (Bruce Henderson)
  16.  
  17.        What if an objective-C message pass (a somewhat computationally 
  18.        expensive thing) was a processor level thing, and say happened in 
  19.        3 clocks?
  20.  
  21. Unfortunately this doesn't turn out to be as big a win as you think.
  22. Basically, smarter cacheing and optimization of certain lookup cases
  23. can get you more than hashing hardware.  For instance, the
  24. memoization-dispatch scheme in PCL turned out to be faster than a
  25. dispatch using lookup hardware (on the lisp machine).  Ultimately this
  26. boils down to the RISC vs CISC debate again.
  27.  
  28. There are other reasons for using a writable control store, and you
  29. touch on them in your message.  But many of the interesting
  30. optimizations one can imagine turn out not to be the big win one
  31. imagines at first.  Too bad, eh?
  32.