home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / intel / 2785 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  4.9 KB
  1. Xref: sparky comp.sys.intel:2785 comp.arch:11788
  2. Path: sparky!uunet!pipex!warwick!uknet!gdt!aber!fronta.aber.ac.uk!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.92Dec19165907@decb.aber.ac.uk>
  7. Date: 19 Dec 92 16:59:07 GMT
  8. References: <1992Dec7.012026.11482@athena.mit.edu>
  9.     <1992Dec8.000357.26577@newsroom.utas.edu.au>
  10.     <PCG.92Dec9154602@aberdb.aber.ac.uk>
  11.     <1992Dec12.152224.168173@zeus.calpoly.edu>
  12. Sender: news@aber.ac.uk (USENET news service)
  13. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  14. Organization: Prifysgol Cymru, Aberystwyth
  15. Lines: 88
  16. In-Reply-To: mneideng@thidwick.acs.calpoly.edu's message of 12 Dec 92 15: 22:24 GMT
  17. Nntp-Posting-Host: decb.aber.ac.uk
  18.  
  19.  
  20. On 12 Dec 92 15:22:24 GMT, mneideng@thidwick.acs.calpoly.edu (Mark
  21. Neidengard) said:
  22.  
  23. mneideng> I see nothing wrong with many instruction units on one chip;
  24. mneideng> all you have to do is either A) use them like a sort of
  25. mneideng> on-chip diastolic pipeline, or B) have the system process
  26. mneideng> scheduler schedule different processes to use different units.
  27.  
  28. Wonderful ideas! What I would actually like is a dataflow machine, then.
  29.  
  30. mneideng> I could easily envision a chip with three FP adders and three
  31. mneideng> FP multipliers (maybe not with today's fabrication, but in
  32. mneideng> another year or so...)  What you would have to do is increase
  33. mneideng> the sophistication of the chip's internal pipeline controller
  34. mneideng> and do a LOT of instruction predecoding.
  35.  
  36. Easy said, easy done :-). A lot of research is going into that; as
  37. somebody posted there is a law that says that exploitable parallelism is
  38. a linear function of the ASPLOS number.
  39.  
  40. But my point is not tabout not being able to do that; my point is about
  41. it being necessary or even useful.
  42.  
  43. Given that there has been some incomprehension as to which issue I
  44. thought we were discussing, I will try to reformulate it again.
  45.  
  46. The important limit to micro/macro parallelism is not the cleverness of
  47. the CPU implementor, it is the inherent parallelism in the
  48. application/algorithm/data strctures.
  49.  
  50. As far as I have read and seen with my eyes, let me insist, most
  51. "general purpose" codes have limited degrees of exploitable micro/macro
  52. parallelism, say 2 to 4. The underlying reason is that most such codes
  53. are about is serial tree/graph walking/updating.
  54.  
  55. Codes with easily "minable" parallelism are, almost invariably, "special
  56. purpose" codes, the underlying reason is that most such codes are about
  57. sequential array scanning/filtering, and even on those a trivial thing
  58. as strides may cause problems.
  59.  
  60. Then in a much distant second position, are "one purpose" codes, for
  61. very special applications, such as those beloved by NSA. If there is any
  62. undrlying commonality to "one purpose" codes is probably that they are
  63. about associative access to memory, rather than graph walking or array
  64. scanning.
  65.  
  66. Now, whatever architecture, even superscalar/multiple functional
  67. units/dataflow/systolic/VLIW or whatever trickery cannot extract from
  68. "general purpose" codes more parallelism than they intrinsically contain
  69. (Amdahl's law rules).
  70.  
  71. The real issue we are discussing here is whether superscalar/multiple
  72. FUs/dataflow/systolic/VLIW are well suited to codes with high inherent,
  73. array like, parallelism. As to this I beg to submit that a special
  74. purpose architecture, vector, for a special purpose data structure,
  75. array, is the most cost/effective bet still. Hennessy and Patterson seem
  76. to say so in the first two pages of their book, incidentally.
  77.  
  78. So let's go back to the original question: given that we shall shortly
  79. be able to have about half a dozen/a dozen functional units on a die,
  80. how should these be arranged?
  81.  
  82. 1) As a single systolic/dataflow engine (or rather a poor imitation
  83. thereof, e.g. a supersuperscalar with lots of Tomasulization/register
  84. renaming tricks)?
  85.  
  86. 2) As multiple superscalar[+vector] CPUs?
  87.  
  88. I think that the second option looks more promising, from my armchair
  89. (I would be happy to receive as a donation a state-of-the-art CAD system
  90. for designing CPUs, and a fab line for 3 million transistor chips).
  91.  
  92. The reasons are that the superscalar part can take advantage of the
  93. limited inherent microparallelism of most codes, the vector part can
  94. deal with the occasional but very important (graphics, sound, etc.)
  95. vector codes, and the limited degree of multiprocessing would allow
  96. exploiting the limited degree of macro parallelism in most applications.
  97.  
  98. Just to make things clearer, I am thinking of the workstation of a few
  99. years hence, with realtime animated video, interactive WSYWYG hypertext,
  100. an integrated telephone, and running DOS 7/Windows 3.9 :-).
  101.  
  102. This seems to be Intel's own vision, incidentally.
  103. --
  104. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  105.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  106.   alle orecchie del suo divino protettore, il dio della barzelletta
  107.