home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11953 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  3.4 KB
  1. Xref: sparky comp.arch:11953 comp.sys.intel:2841
  2. Path: sparky!uunet!europa.asd.contel.com!gatech!usenet.ins.cwru.edu!agate!doc.ic.ac.uk!uknet!gdt!aber!fronta.aber.ac.uk!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.92Dec27200733@decb.aber.ac.uk>
  7. Date: 27 Dec 92 20:07:33 GMT
  8. References: <1992Dec7.012026.11482@athena.mit.edu> <PCG.92Dec11162630@aberdb.aber.ac.uk>
  9.     <PCG.92Dec23144916@decb.aber.ac.uk>
  10.     <1992Dec23.164617.8055@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: 53
  15. In-Reply-To: solman@athena.mit.edu's message of 23 Dec 92 16: 46:17 GMT
  16. Nntp-Posting-Host: decb.aber.ac.uk
  17.  
  18. On 23 Dec 92 16:46:17 GMT, solman@athena.mit.edu (Jason W Solinsky) said:
  19.  
  20. solman> We seem to be saying the same things only you keep on talking
  21. solman> about macro-level parallelism as though it would be difficult to
  22. solman> exploit, and I feel that the existence of macro-level
  23. solman> parallelism justifies increased superscalarity.
  24.  
  25. It's your very feeling that I find very, very optimistic, and totally
  26. unsupported by past experience. But maybe I am too conservative, and I
  27. hope that I am wrong. After all the human brain seems to be built like
  28. you say, as a very highly parallel dataflow engine, not a massively
  29. (macro) parallel machine.
  30.  
  31. solman> It is my contention that as processors continue to get more and
  32. solman> more hyperscalar, they will be increasingly able to exploit
  33. solman> macro-level parallelism without the help of smart compilers
  34.  
  35. As a contention, stated so bluntly, it stands on its own. I can only
  36. repeat that I am skeptical, as the experience so far seems that basic
  37. block level parallelism (which can exploited with multiple functional
  38. units within the same CPU) is quite a different thing from continuation
  39. level parallelism (which can be exploited with multiple CPUs within the
  40. same machine).
  41.  
  42. solman> In a hyperscalar chip it will be necessary to implement tagging
  43. solman> and/or scoreboarding protocols to control resource allocation
  44. solman> and make sure that none of the data gets mixed up.
  45.  
  46. One of the big problems in going from the basic block to the
  47. continuation level is that scheduling basic blocks is relatively easy,
  48. as there are no conditional branches, or at most you deal with loops
  49. (I am discounting heroic attempts to fit things like trace scheduling to
  50. general purpose codes).
  51.  
  52. Getting multiple threads to run within the same CPU requires more than a
  53. bit of things like speculative execution, and maybe even backtracking.
  54.  
  55. solman> Once this overhead is paid, the protocols can be altered to find
  56. solman> macro level parallelism on their own with very little additional
  57. solman> cost in either performance or area.
  58.  
  59. More than overhead I would say that the problem is that as of now nobody
  60. have got the faintest clue on how to make this work in particular cases,
  61. not to mention in the general case. I'd love to be proved underinformed
  62. on this.
  63.  
  64. Maybe you are thinking of something like Hewitt's ideas on actor based
  65. computing; but to me they look like an imaginative way organize macro
  66. level parallelism.
  67. --
  68. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  69.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  70.   alle orecchie del suo divino protettore, il dio della barzelletta
  71.