home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11830 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  5.1 KB
  1. Xref: sparky comp.arch:11830 comp.sys.intel:2802
  2. Newsgroups: comp.arch,comp.sys.intel
  3. Path: sparky!uunet!timbuk.cray.com!walter.cray.com!ferris!bradc
  4. From: bradc@ferris.cray.com (Bradley R. Carlile)
  5. Subject: Re: Superscalar vs. multiple CPUs ?
  6. Message-ID: <1992Dec21.134909.6185@walter.cray.com>
  7. Keywords: VLIW, vector, superscalar
  8. Lines: 87
  9. Nntp-Posting-Host: ferris.cray.com
  10. Organization: Cray Research, Inc.
  11. References: <PCG.92Dec9154602@aberdb.aber.ac.uk> <1992Dec9.211737.23911@walter.cray.com> <PCG.92Dec11162630@aberdb.aber.ac.uk>
  12. Date: 21 Dec 92 13:49:09 CST
  13.  
  14. > On 10 Dec 92 03:17:36 GMT, bradc@ferris.cray.com (Bradley R. Carlile) said:
  15. > 
  16. > pcg> as far as I can see, 6 instruction issue per cycle is virtually
  17. > pcg> pointless. The *limit* of superscalarity present in general purpose
  18. >                              ^^^^^^^^^^^^^^^
  19. > Piercarlo Grandi writes:
  20. > Note the "general purpose"; if the codes exhibit high regularity in data
  21. > access patterns then they are no longer "general purpose" codes, at
  22. > least in my understanding of that term, which encompasses things like
  23. > editors, databases, compilers, word processors, spreadsheets, ...
  24.  
  25. Well these general pupose codes also involve code sections that can be
  26. software pipelined.  Things like searching, sorting, list updates, ...
  27. As I see it, there are several levels of parallelism.  We want to use
  28. different techniques at different grainularities (Instruction, Machine, 
  29. cluster, network,...).  I agree there is a limit to instruction level 
  30. parallelism that depends on the code.  But we could use more than 4.  
  31. We may need more instructions than 2 to get that average level of speedup.
  32.  
  33. > pcg> codes is 4, and actually we are hard pressed to find many codes
  34. > pcg> with superscalarity higher than 2.
  35.  
  36. > bradc> The limit of 4 or 6 may be the limit programming a superscalar
  37. > bradc> chip like by simply letting the the chip group instructions
  38. > bradc> together.  *However* if one uses the technique of software
  39. > bradc> pipelining like we used to use on the VLIW machines of yesteryear
  40. > bradc> FPS-120B (before 1976), FPS-164, and the FPS-264 (1985?).
  41. > 
  42. > Ah yes, well known, for codes well suited to SIMD style computing. But
  43. > frankly the jury is still out on software pipelining even in that case.
  44. > It covers, like LIW/VLIW, a gray area between [super]scalar and vector,
  45. > one maybe suited to short vector lengths.
  46. > 
  47. > bradc> These machines could issue up to 10 instruction every cycle {I
  48. > bradc> wrote software for 7 years that used these instructions}.
  49. > 
  50. > But I still think that a proper vector processor is overall, except for
  51. > particular cases, a better bet, especially because memory queues fit in
  52. > more easily with a vector architecture than with everything else, and
  53. > SIMD-style codes are great bandwidth eaters. And one can design vector
  54. > architectures that do perform well even for the short vector length for
  55. > which a LIW/VLIW seems designed.
  56.  
  57. My point here is would be that VLIW is more general than vector processing,
  58. my experience shows that there more codes/loops can be software pipelined than
  59. vectorized.  
  60.  
  61. > Also, If you can put to good use software pipelining, and issue 10
  62. > instructions per cycle, this means you have the same order of magnitude
  63. > memory transactions, and you need the same order of magnitude register
  64. > file depths, and so on. This looks like calling for vector instructions,
  65. > vector registers, vector memory access.
  66.  
  67. You are not necessarily adding memory transactions.  Only two of those 
  68. 10 instructions that I mentioned earlier where memory.  Memory issues
  69. can be separated from the manner in which data is moved.
  70.  
  71. We need to be able to use different techniques at different levels.  VLIW for 
  72. effective instrution issue and other techniques to uses caches like vector 
  73. registers.  An example of this it is the CRAY APP (84 processor shared memory
  74. machine that uses these techniques [I do not include this as an advertisment,
  75. but as a proof of concept].
  76.  
  77. > bradc> In addition, compilers can automatically perform software
  78. > bradc> pipelining. At FPS we had several.  A "modern" example of a
  79. > bradc> compiler includes Portland Group Inc.'s i860 compiler.
  80. > 
  81. > Fascinating compilers, but the i860 story (which is often considered a
  82. > sort of LIW architecture) seems to support my impressions: it would have
  83. > been easier, even for the limited degree of parallelism available in the
  84. > i860, to have proper vector style instructions; the ones that do exploit
  85. > the multiple functional units of the i860 really amount to such, only
  86. > with loads of complications and hazards, and difficulties with keeping
  87. > the pipes fed. Now the i860 is a particularly awkward quasi-LIW design,
  88. > and it should not be taken as a straw man, but still...
  89.  
  90. I think that the i860 is a VLIW processor (no one seems to use the term LIW
  91. anymore).  However we have used software pipelining effectively on 
  92. superscalar machines.  I agree the i860 has problems, but I feel I could
  93. get codes to run faster on a VLIW (and more of them) than on a vector processor
  94. of the same clock rate.  
  95.  
  96. My basic point is I think the VLIW is just a programmable vector processor.
  97.  
  98. Brad Carlile
  99. Cray Research Superservers, Inc.
  100. bradc@oregon.cray.com
  101.