home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11955 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  2.8 KB
  1. Xref: sparky comp.arch:11955 comp.sys.intel:2842
  2. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!spool.mu.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.92Dec27201257@decb.aber.ac.uk>
  7. Date: 27 Dec 92 20:12:57 GMT
  8. References: <PCG.92Dec11162630@aberdb.aber.ac.uk> <1992Dec21.134531.3253@athena.mit.edu>
  9.     <PCG.92Dec23144916@decb.aber.ac.uk> <Bzpzwq.18q@news.udel.edu>
  10. Sender: news@aber.ac.uk (USENET news service)
  11. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  12. Organization: Prifysgol Cymru, Aberystwyth
  13. Lines: 41
  14. In-Reply-To: mccalpin@perelandra.cms.udel.edu's message of 23 Dec 92 16: 17:13 GMT
  15. Nntp-Posting-Host: decb.aber.ac.uk
  16.  
  17. On 23 Dec 92 16:17:13 GMT, mccalpin@perelandra.cms.udel.edu (John D. McCalpin) said:
  18. Nntp-Posting-Host: perelandra.cms.udel.edu
  19.  
  20. mccalpin> (Piercarlo Grandi) writes:
  21.  
  22. solman> At any rate, I would claim that improvements in processor
  23. solman> performance should only be concerned with apps which are
  24. solman> presently processor limited, and many of these general purpose
  25. solman> codes just aren't.
  26.  
  27. pcg> Uhm, memory is so cheap that many "general purpose" applications
  28. pcg> nowadays can be made entirely core resident, and a core resident
  29. pcg> program is 100% CPU bound.  for example I see most compiles on my
  30. pcg> machine are CPU bound; except for reading in the source and writing
  31. pcg> out the code there is no IO activity whatsoever.
  32.  
  33. mccalpin> I disagree with this distinction.  A core resident program can
  34. mccalpin> be very seriously *memory* bound if the processor is spending
  35. mccalpin> most of its time locked down waiting for cache misses to be
  36. mccalpin> filled.
  37.  
  38. Ah, of course, this is the next problem that a hyperscalar architecture
  39. has got to solve. Given the less than impressive rate of improvement in
  40. memory speeds, most fast CPUs today are memory starved, as you comment
  41. on later.
  42.  
  43. This is another reason for which I think hyperscalar is premature:
  44. a vector instruction has the very nice property that it implies a very
  45. definite memory access pattern, as compared with a loop that does the
  46. same thing. And many important applications have FIFO data reference
  47. patterns, for which predictive memory accesses are essential, and
  48. adaptive ones, like those implied by a cache, are fatal:
  49.  
  50. mccalpin> Many "cpu-bound" programs spend half or more of their time in
  51. mccalpin> this state, and it is very easy to accidentally build a
  52. mccalpin> program which spends 90% of its time waiting for cache line
  53. mccalpin> refills.
  54. --
  55. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  56.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  57.   alle orecchie del suo divino protettore, il dio della barzelletta
  58.