home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / lisp / mcl / 1884 < prev    next >
Encoding:
Text File  |  1992-12-23  |  1.7 KB  |  37 lines
  1. Newsgroups: comp.lang.lisp.mcl
  2. Path: sparky!uunet!spool.mu.edu!agate!boulder!cambridge.apple.com!news.cambridge.apple.com!news.media.mit.edu!enterpoop.mit.edu!snorkelwacker.mit.edu!stanford.edu!CSD-NewsHost.Stanford.EDU!Xenon.Stanford.EDU!michaelg
  3. From: michaelg@Xenon.Stanford.EDU (Michael Greenwald)
  4. Subject: Re: Speed freak needs help
  5. Message-ID: <725142704.18538@news.Colorado.EDU>
  6. Lines: 20
  7. Sender: news
  8. Organization: CS Department, Stanford University, California, USA
  9. References: <9212231553.AA22788@cambridge.apple.com>
  10. Distribution: co
  11. Date: 23 Dec 92 19:40:41 GMT
  12. Approved: news
  13. X-Note1: mail msgid was <michaelg.725139641@Xenon.Stanford.EDU>
  14. X-Note2: message-id generated by recnews
  15. Lines: 20
  16.  
  17. moon (David A. Moon) writes:
  18.  
  19. >                            Symbolics still makes 
  20. >Lisp machines, but again without having measured them I think you would find 
  21. >performance on the latest Symbolics machine similar to or less than the 
  22. >Quadra.  (The Symbolics clock rate is half the Quadra clock rate, but the 
  23. >architecture is not much more than twice as efficient.)
  24.  
  25. I don't know the numbers, this is a non-rhetorical question: How does
  26. the Symbolics single float implementation stack up against the Quadra?
  27. (I'm assuming that the Quadra conses its floats, while the LispM uses
  28. immediates).  If (and it's a big "if"), the application in question is
  29. float-intensive, and the GC is taking a significant part of the
  30. overhead, then perhaps the Symbolics machines (or any machine with
  31. immediate single floats) can give a reasonable performance boost.
  32.  
  33. But for a factor of 10 or 20, the answer (if any) probably lies in:
  34.  
  35. >Are you sure the algorithm can't be optimized?  Sometimes that's the fastest 
  36. >and cheapest way to get more speed.  But maybe you already tried that.
  37.