home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10453 < prev    next >
Encoding:
Text File  |  1992-11-07  |  3.2 KB  |  67 lines

  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!walter!gizmo!mo
  3. From: mo@gizmo.bellcore.com (Michael O'Dell)
  4. Subject: Re: RTX and SC32
  5. Message-ID: <1992Nov6.131717.15715@walter.bellcore.com>
  6. Keywords: 
  7.  
  8. Sender: news@walter.bellcore.com
  9. Nntp-Posting-Host: gizmo.bellcore.com
  10. Reply-To: mo@bellcore.com
  11. Organization: Center for Chaotic Repeatabilty
  12. References: <17131@mindlink.bc.ca> <1992Nov4.191038.12063@news.arc.nasa.gov> <1dcvsmINNiop@uniwa.uwa.edu.au>
  13. Date: Fri, 6 Nov 92 13:17:17 GMT
  14. Lines: 51
  15.  
  16. "Stacks always go in memory, and you always go to the stack."
  17.  
  18. Well, if you wanted a damning case against very fast stack machines,
  19. i can't imagine a better one than that.
  20.  
  21. The simple reality is that processors get faster much more quickly than
  22. affordable memory components, hence the only way you can feed this new
  23. generation of blisteringly-quick processors (regardless of the
  24. architectural fru-fru) is to build a complex  memory system (read this as
  25. EXPENSIVE by comparison to simple minis and workstations).  The only way
  26. you can go fast is to avoid touching deathly-slow memories, and when you
  27. do, you gotta hack like hell to go as fast as possible.  That's why fast
  28. RISC machines gotta be surrounded by  (or contain) instruction caches with
  29. burst-fill (or something morally similar), and why they gotta have very
  30. clever data caches with all kinds of nifty tricks like out-of-order
  31. completion allowed, and/or deep write-buffer queues with associative
  32. bypass for fast back-filling, and such.  If you touch memory, you lose,
  33. pure and simple. There is no way an Alpha instruction pipeline (to pick
  34. one at random) can go *LOTS* faster than an R2000 instruction pipe if it
  35. is forced to touch 80ns dynamic memory chips with the same frequency and
  36. with the same available memory bandwidth, ie, without a sophisticated
  37. memory subsystem in between somewhere.
  38.  
  39. What does this have to do with Stack Machines?? LOTS.  The biggest
  40. performance kicker in the Burroughs 7800 (come 7900) was
  41. the introduction of a largish (for the time and available technology)
  42. asynchronous stack-top cache.  It helped performance dramatically.
  43. So, fast stack machines can play the memory system game - get
  44. themselves large stack-top caches and good instruction caches.
  45. (but don't forget what huge cache contexts do to context switch
  46. time and how fast the machine runs at one MIPS after a switch while
  47. the cache cold-starts).  But the what happened to the simplicity,
  48. cheapness, and low transitor count?
  49.  
  50. And more importantly, does it really go as fast???
  51.  
  52. What I have not seen in the literature (which doesn't mean it doesn't
  53. exist, just that i haven't seen it) is a comparison of a stack machine
  54. design with the equivalent complexity budget of modern RISC machines
  55. to such modern processors.  By complexity budget I mean one that spends
  56. as much logic on cache and memory system complexity as the fast RISC
  57. machines do.   (including the related trickle-down complexity like
  58. dealing with out-of-order completion in the pipe, if required)
  59.  
  60. Note that we may have an interesting data point in this discussion:
  61. the Hobbit may be close enough to this last model to be interesting.
  62. We'll have to wait and see.
  63.  
  64.     -Mike O'Dell
  65.  
  66. Bellcore?? Bellcore isn't allowed opinions. Any found here are mine.
  67.