home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11824 < prev    next >
Encoding:
Text File  |  1992-12-21  |  2.6 KB  |  61 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!stanford.edu!nntp.Stanford.EDU!bwilson
  3. From: bwilson@leland.Stanford.EDU (Robert Wilson)
  4. Subject: Re: Superscalar vs. multiple CPUs ?
  5. Message-ID: <1992Dec21.173732.14154@leland.Stanford.EDU>
  6. Sender: news@leland.Stanford.EDU (USENET News System)
  7. Organization: DSG, Stanford University, CA 94305, USA
  8. References: <lj976dINNg4d@exodus.Eng.Sun.COM>
  9. Date: Mon, 21 Dec 92 17:37:32 GMT
  10. Lines: 49
  11.  
  12.  
  13. In article <lj976dINNg4d@exodus.Eng.Sun.COM> grover@brahmand.Eng.Sun.COM (Vinod Grover) writes:
  14. > I suggest you read the Butler et. al. paper cited [1] earlier by someone
  15. > in this thread. These authors claim that on an unrestricted data flow
  16. > machine, *general purpose* codes like gcc, li, eqntott, (taken from
  17. > SPEC89) have pretty high degree of parallelisms in them. Measured in
  18. > terms of IPC:
  19. > 
  20. >   gcc - 38
  21. >   espresso - 179
  22. >   eqntott - 300
  23. >   li - 162
  24. > 
  25. > Judging from these claims, the issue is not how much parallelism there
  26. > is but how cost-effective is it to extract it. As CPU resources
  27. > approach realistic values the sustainable issue rates on these codes
  28. > fall dramatically, (2-4). These are limits imposed by the
  29. > hardware/compilers. 
  30. > 
  31. > [1] Butler, Yeh, Patt, Alsup, Scales, Shebanow, "Single Instruction
  32. > Stream Parallelism is Greater than Two", Intnl. Symp. on Comp. Arch
  33. > 1991. 
  34.  
  35. Unfortunately, the limited degree of parallelism in general-purpose
  36. codes is NOT just due to the current state of hardware and compilers.
  37. The study by Butler et al. contains some interesting results and is
  38. definitely worth reading but don't put too much weight on the numbers
  39. for the Unrestricted Dataflow (UDF) Machine.  This machine only considers
  40. data dependences.  In the programs mentioned above, however, most of the
  41. computation centers around executing branches, so the limiting factor is
  42. not just WHEN can the instructions execute, but also WHICH instructions
  43. will be executed.  The UDF machine completely ignores these control
  44. dependences which are an inherent part of the program semantics and not
  45. just a side effect of limited hardware and compilers.
  46.  
  47. There are, of course, some things we can do to try to mitigate the
  48. effects of control dependences.  Branch prediction with speculative
  49. execution, control dependence analysis, and multiple processors are
  50. three things that we have found so far [2].  As new techniques are
  51. developed, we can certainly expect to extract more parallelism from
  52. general-purpose codes, but for now, I think 2 - 4 is a reasonable
  53. estimate for the IPC of a uniprocessor.
  54.  
  55. Bob Wilson
  56. bwilson@shasta.stanford.edu
  57.  
  58. [2] Monica Lam and Robert Wilson, "Limits of Control Flow on Parallelism",
  59. 19th Intnl. Symp. on Comp. Arch, 1992.
  60.  
  61.