home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11899 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  2.5 KB
  1. Xref: sparky comp.arch:11899 comp.sys.intel:2824
  2. Newsgroups: comp.arch,comp.sys.intel
  3. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!news.udel.edu!perelandra.cms.udel.edu!mccalpin
  4. From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin)
  5. Subject: Re: Superscalar vs. multiple CPUs ?
  6. Message-ID: <Bzpzwq.18q@news.udel.edu>
  7. Sender: usenet@news.udel.edu
  8. Nntp-Posting-Host: perelandra.cms.udel.edu
  9. Organization: College of Marine Studies, U. Del.
  10. References: <PCG.92Dec11162630@aberdb.aber.ac.uk> <1992Dec21.134531.3253@athena.mit.edu> <PCG.92Dec23144916@decb.aber.ac.uk>
  11. Date: Wed, 23 Dec 1992 16:17:13 GMT
  12. Lines: 37
  13.  
  14. In article <PCG.92Dec23144916@decb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
  15. >On 21 Dec 92 13:45:31 GMT, solman@athena.mit.edu (Jason W Solinsky) said:
  16. >
  17. >solman> At any rate, I would claim that improvements in processor
  18. >solman> performance should only be concerned with apps which are
  19. >solman> presently processor limited, and many of these general purpose
  20. >solman> codes just aren't.
  21. >
  22. >Uhm, memory is so cheap that many "general purpose" applications
  23. >nowadays can be made entirely core resident, and a core resident program
  24. >is 100% CPU bound.  for example I see most compiles on my machine are
  25. >CPU bound; except for reading in the source and writing out the code
  26. >there is no IO activity whatsoever.
  27.  
  28. I disagree with this distinction.  A core resident program can be very
  29. seriously *memory* bound if the processor is spending most of its time
  30. locked down waiting for cache misses to be filled.   Many "cpu-bound"
  31. programs spend half or more of their time in this state, and it is very
  32. easy to accidentally build a program which spends 90% of its time
  33. waiting for cache line refills.
  34.  
  35. Common applications such as text editting of large files (i.e. files
  36. significantly larger than cache) could benefit considerably from
  37. decreasing cache latency and would often benefit from having wider
  38. memory-to-cache buses.
  39.  
  40. Although I don't think it was ever done, the world's fastest text
  41. editor could probably have been written for the ETA-10, which had a
  42. bewildering variety of instructions for copying and searching chunks of
  43. its bit-addressable memory at vector speeds.   The Cray machines could
  44. be competitive, but the lack of byte addressability makes working with
  45. text awkward and relatively slow.
  46. -- 
  47. --
  48. John D. McCalpin                        mccalpin@perelandra.cms.udel.edu
  49. Assistant Professor                     mccalpin@brahms.udel.edu
  50. College of Marine Studies, U. Del.      John.McCalpin@mvs.udel.edu
  51.