home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / intel / 2823 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  4.9 KB
  1. Xref: sparky comp.sys.intel:2823 comp.arch:11898
  2. Path: sparky!uunet!pipex!bnr.co.uk!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.92Dec23150744@decb.aber.ac.uk>
  7. Date: 23 Dec 92 15:07:44 GMT
  8. References: <WAYNE.92Dec4093422@backbone.uucp> <37595@cbmvax.commodore.com>
  9.     <PCG.92Dec13170504@aberdb.aber.ac.uk>
  10.     <1992Dec21.133318.2975@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: 77
  15. In-Reply-To: solman@athena.mit.edu's message of 21 Dec 92 13: 33:18 GMT
  16. Nntp-Posting-Host: decb.aber.ac.uk
  17.  
  18. On 21 Dec 92 13:33:18 GMT, solman@athena.mit.edu (Jason W Solinsky) said:
  19.  
  20. solman> If you define the codes which we are concerned with to be codes
  21. solman> which can only exploit ILP, then of course the level of
  22. solman> parallelism is limited, but you are not dealing with general
  23. solman> purpose computing anymore.
  24.  
  25. Ah, this discussion was indeed mostly about ILP/superscalarity/VLIW.
  26.  
  27. pcg> Indeed pipeline designs with more than a few stages of pipelining
  28. pcg> run into huge problems, and are worth doing only if a significant
  29. pcg> proportion of SIMD-like operation is expected. Pipeline bubbles
  30. pcg> start to become a significant problem beyond 4 pipeline stages on
  31. pcg> general purpose codes, even on non superscalar architectures.
  32.  
  33. solman> This can be taken care of by interleaving different threads in
  34. solman> the software, or using hardware which will take care of the
  35. solman> interleaving on its own. The above statement is only true when
  36. solman> the compiler is too dumb to notice higher level parallelism.
  37.  
  38. Well, here you are saying, if I read you right, that if an application
  39. is suited to MIMD style computing then multithreading is the answer.
  40. This in itself is nearly a tautology. If you are also implying that many
  41. more applications are suited to *massive* MIMD style (macro) parallelism
  42. then is commonly believed, I would ber skeptical; what I believe is that
  43. quite a few *important* applications can be successfully (macro)
  44. parallelized, MIMD style. For example compiling GNU Emacs; each
  45. compilation of each source module can proceed in parallel, and indeed
  46. one can spawn a separate thread for each function in each source module.
  47.  
  48. solman> The key question in chosing how large register files and caches
  49. solman> should be, is "How large a {register file or cache} do I need
  50. solman> for `good' performance on the algorithms I want to run?"
  51. solman> Invariably, the size chosen is too small some of the time, while
  52. solman> much of it is left unused at other times. In the multiple CPU
  53. solman> version, this still happens. In the hyperscalar version,
  54. solman> however, some of the execution units and threads will need a
  55. solman> larger {cache or reg file} and some will be unable to utilize
  56. solman> the existing space, but because they can share the same caches
  57. solman> and register files, it is far less likely for performance to be
  58. solman> limited by cache or register file size.
  59.  
  60. I agree with the sentiment here; partitioning resources can indeed lead
  61. to starvation in one place but to overcommitment in another.
  62.  
  63. The problem is that sharing resources can have tremendous costs; sharing
  64. register files between multiple parallel functional units looks nice
  65. until one figures out the cost in terms of multiporting.
  66.  
  67. It's obvious you know this, but maybe you are underestimating this cost;
  68. moreover avoiding partitioning will really solve problems only when
  69. there are huge swings in resource allocations by different threads; if
  70. these are fairly predictable, then static partitioning does not look so
  71. bad. I reckon that this is the case in many instances. Vectorization is
  72. successful precisely because a lot of common important applications
  73. (array oriented ones) have fairly predictable resource profiles, and so
  74. you can build the architecture around them.
  75.  
  76. solman> [ ... ] Its an open question on how you want to do it. I
  77. solman> personally favor tagging everything, and avoiding the concept of
  78. solman> contexts in a dataflowish fashion.
  79.  
  80. Ah, this again would be my sentiment; I am a great admirer for example
  81. fo the Manchester Dataflow prototype. But the practicality of the thing
  82. is that dataflowish machines are built for the worst possible case
  83. (everything unpredictable and fluid), while 80% of important codes are
  84. quite more statically so, and taggint everything is quite a waste then.
  85.  
  86. The open research question is how to run as fast as possible on 80% of
  87. codes while not defining an architecture that is unsuited for the
  88. remaining 20%. As to this I think that a dirtier design, a compromise,
  89. will work better than a neat fluid tagged dataflow machine. I only hoppe
  90. I am wrong.
  91. --
  92. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  93.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  94.   alle orecchie del suo divino protettore, il dio della barzelletta
  95.