home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / arch / 11705 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  3.1 KB
  1. Xref: sparky comp.arch:11705 comp.sys.intel:2734
  2. Path: sparky!uunet!pipex!bnr.co.uk!uknet!gdt!aber!aberfa!pcg
  3. From: pcg@aber.ac.uk (Piercarlo Grandi)
  4. Newsgroups: comp.arch,comp.sys.intel
  5. Subject: Re: Superscalar vs. multiple CPUs ?
  6. Message-ID: <PCG.92Dec13164348@aberdb.aber.ac.uk>
  7. Date: 13 Dec 92 16:43:48 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.     <1992Dec9.211737.23911@walter.cray.com> <Bz25n0.202@metaflow.com>
  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: 47
  16. In-Reply-To: rschnapp@metaflow.com's message of 10 Dec 92 19: 18:35 GMT
  17. Nntp-Posting-Host: aberdb
  18.  
  19. On 10 Dec 92 19:18:35 GMT, rschnapp@metaflow.com (Russ Schnapp) said:
  20.  
  21. rschnapp> (Bradley R. Carlile) writes:
  22.  
  23. Bradley> The limit of 4 or 6 may be the limit programming a superscalar
  24. Bradley> chip like by simply letting the the chip group instructions
  25. Bradley> together.  *However* if one uses the technique of software
  26. Bradley> pipelining like we used to use on the VLIW machines of
  27. Bradley> yesteryear FPS-120B (before 1976), FPS-164, and the FPS-264
  28. Bradley> (1985?).  These machines could issue up to 10 instruction every
  29. Bradley> cycle {I wrote software for 7 years that used these
  30. Bradley> instructions}.
  31.  
  32. rschnapp> Don't forget about out-of-order (i.e., dataflow) execution
  33. rschnapp> techniques.  You can gain plenty of additional fine-grain
  34. rschnapp> parallelism.
  35.  
  36. Ah, there are indeed many interesting tricks to support high levels of
  37. micro parallelism *in the implementation*. To me the really interesting
  38. problem is not how to do it, though, it is whether it is worth doing it,
  39. and for which classes of codes.
  40.  
  41. I have yet to find evidence that *general purpose* codes have an
  42. intrinsic degree of micro parallelizable operation (let's call it
  43. superscalarity) that makes it worthwhile to have a degree of parallel
  44. *instruction issue* within a single stream not greater than 2-4.
  45.  
  46.   The codes that can be easily micro-parallelized are usually *special
  47.   purpose*, in that they have a structure (e.g.  FIFO reference patterns)
  48.   that are best suited to a SIMD/vector processor approach.
  49.  
  50. Otherwise *general purpose* codes have a degree of macro parallelism
  51. (let's call it multithreading) that can be best exploited with multiple
  52. CPUs, and that can exploited up to a degree of parallel *instruction
  53. streams* with independent contexts not greater than 2-4 (again).
  54.  
  55.   Then are are codes that can be easily macro-parallelized, and these
  56.   are again *special purpose*, in that they have a structure (e.g.
  57.   LIFO reference patterns) that are best suited to a MIMD approach.
  58.  
  59. Naturally all this depends on how you define a "code"; for example a
  60. timesharing system might be considered a single, highly parallelizable
  61. code, or as a collection of fairly hard to parallelize different codes.
  62. --
  63. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  64.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  65.   alle orecchie del suo divino protettore, il dio della barzelletta
  66.