home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / intel / 2733 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  5.0 KB
  1. Xref: sparky comp.sys.intel:2733 comp.arch:11704
  2. Path: sparky!uunet!pipex!bnr.co.uk!uknet!gdt!aber!aberfa!pcg
  3. From: pcg@aber.ac.uk (Piercarlo Grandi)
  4. Newsgroups: comp.sys.intel,comp.arch
  5. Subject: Re: Superscalar vs. multiple CPUs ?
  6. Message-ID: <PCG.92Dec13170504@aberdb.aber.ac.uk>
  7. Date: 13 Dec 92 17:05:04 GMT
  8. References: <WAYNE.92Dec4093422@backbone.uucp> <37595@cbmvax.commodore.com>
  9.     <PCG.92Dec9154602@aberdb.aber.ac.uk>
  10.     <1992Dec10.002951.23336@athena.mit.edu>
  11. Sender: news@aber.ac.uk (USENET news service)
  12. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  13. Organization: Prifysgol Cymru, Aberystwyth
  14. Lines: 91
  15. In-Reply-To: solman@athena.mit.edu's message of 10 Dec 92 00: 29:51 GMT
  16. Nntp-Posting-Host: aberdb
  17.  
  18. On 10 Dec 92 00:29:51 GMT, solman@athena.mit.edu (Jason W Solinsky) said:
  19. Nntp-Posting-Host: m4-035-15.mit.edu
  20.  
  21. solman> (Piercarlo Grandi) writes:
  22. |> (Bernard Gunther) said:
  23.  
  24. No, actually I (pcg) said this:
  25.  
  26. pcg> Well, certain tricks can also be used with multiple CPUs on the
  27. pcg> same die. And these have an important advantage: as far as I can
  28. pcg> see, 6 instruction issue per cycle is virtually pointless. The
  29. pcg> *limit* of superscalarity present in general purpose codes is 4,
  30. pcg> and actually we are hard pressed to find many codes with
  31. pcg> superscalarity higher than 2.
  32.  
  33. solman> Err, I believe those are single threaded codes. If you're only
  34. solman> dealing with one thread at a time, then you might as well not
  35. solman> bother doing putting multiple CPUs on a die either.
  36.  
  37. Precisely my point: single threaded *general purpose* codes have a
  38. limited intrinsic degree of exploitable parallelism .
  39.  
  40. pcg> Naturally if one looks at very regular algorithms one can issue
  41. pcg> many, many instructions, *in sequence*, usually. But at that point
  42. pcg> one is really better off with a proper vector processor; emulating
  43. pcg> a vector processor with a superscalar one is not efficient.
  44.  
  45. solman> It also sounds to me like you are looking at a very narrow
  46. solman> subset of programs.  If this were true then modern heavily
  47. solman> pipelined uPs would be horribly inefficient.
  48.  
  49. Indeed pipeline designs with more than a few stages of pipelining run
  50. into huge problems, and are worth doing only if a significant proportion
  51. of SIMD-like operation is expected. Pipeline bubbles start to become a
  52. significant problem beyond 4 pipeline stages on general purpose codes,
  53. even on non superscalar architectures.
  54.  
  55. solman> It seems to me, however, that most programs can take alot of
  56. solman> parallelism, sometimes even without multithreading.
  57.  
  58. If you have evidence of this you stand to make a fortune, and I am sure
  59. that most computer/compiler vendors would want to hear from you.
  60.  
  61. So far the evidence seems (to me at least) that exploitable degrees of
  62. micro (multiple instruction issue in a cycle) and macro (multiple
  63. instruction streams in a program) parallelism for most codes don't go
  64. above 2-4; only codes with highly regular data reference patterns can be
  65. micro/macro parallelized with success/ease.
  66.  
  67.  
  68. gunther> [ ... on a single chip an internally superscalar/multithreaded
  69. gunther> CPU might be a better idea than multiple independent CPUs ... ]
  70. gunther> At the ISA level, however, the machine might well appear to be
  71. gunther> just a collection of separate CPUs.
  72.  
  73. pcg> Hardly -- there is some problem with multiple contexts and MMUs.
  74.  
  75. solman> These can certainly be taken care of.
  76.  
  77. I may not be current on these issues, I am afraid, but my memories seem
  78. to be that this be an open research problem, and an exceedingly hard one
  79. at that.
  80.  
  81. solman> A lot of hardware is freed up by breaking the "imaginary" lines.
  82.  
  83. Uhmmm, what I read is that almost all the space of modern 1-3 million
  84. CPU chips is taken up by caches and register files.
  85.  
  86. solman> This can then be used to re-implement the lost abilities, like
  87. solman> context switching, but in a manner that allows them to be used
  88. solman> by all the parts of the chip.
  89.  
  90. Again, my impression that designing a multithreaded CPU looks already a
  91. daunting task implies that having the CPU threads execute in different
  92. CPU and MMU contexts (thus having many virtual interrupt vectors,
  93. register files, traps, and instruction restart/resume on faults) looks
  94. harder still. Maybe somebody has already done research along these
  95. lines; maybe it is feasible, and maybe it is even cost effective. I can
  96. only remember old, very limited, and not too successful examples.
  97.  
  98. What I observe is that designing and implementing proper CPU/MMU context
  99. facilities is already hard enough on a single threaded CPU, and becomes
  100. even harder in the presence of deep pipelining or superscalar
  101. implementations. I am not aware of many modern architectures whose
  102. design in this respect is entirely satisfactorily (I read that on the
  103. 88k, one of the better designed architectures, coding trap handlers has
  104. a lot to do with voodoo), not to mention monsters like the i860.
  105. --
  106. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  107.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  108.   alle orecchie del suo divino protettore, il dio della barzelletta
  109.