home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11897 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  4.2 KB
  1. Xref: sparky comp.arch:11897 comp.sys.intel:2822
  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.arch,comp.sys.intel
  5. Subject: Re: Superscalar vs. multiple CPUs ?
  6. Message-ID: <PCG.92Dec23144916@decb.aber.ac.uk>
  7. Date: 23 Dec 92 14:49:16 GMT
  8. References: <1992Dec7.012026.11482@athena.mit.edu> <PCG.92Dec11162630@aberdb.aber.ac.uk>
  9.     <1992Dec21.134531.3253@athena.mit.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: 74
  14. In-Reply-To: solman@athena.mit.edu's message of 21 Dec 92 13: 45:31 GMT
  15. Nntp-Posting-Host: decb.aber.ac.uk
  16.  
  17. On 21 Dec 92 13:45:31 GMT, solman@athena.mit.edu (Jason W Solinsky) said:
  18. Nntp-Posting-Host: m4-035-4.mit.edu
  19.  
  20. solman> (Piercarlo Grandi) writes:
  21.  
  22. pcg> as far as I can see, 6 instruction issue per cycle is virtually
  23. pcg> pointless. The *limit* of superscalarity present in general purpose
  24. pcg>                              ^^^^^^^^^^^^^^^
  25.  
  26. pcg> Note the "general purpose"; if the codes exhibit high regularity in
  27. pcg> data access patterns then they are no longer "general purpose"
  28. pcg> codes, at least in my understanding of that term, which encompasses
  29. pcg> things like editors, databases, compilers, word processors,
  30. pcg> spreadsheets, ...
  31.  
  32. solman> In how many of these examples are we actually concerned with
  33. solman> processor performance? In editors and word processors we
  34. solman> certainly aren't.
  35.  
  36. How innocent! I use both GNU Emacs and Microsoft Word, and they are both
  37. inconsiderate eaters of CPU time, not to mention TeX. The latter eats up
  38. about 10 million instructions per page. As editors and word processors
  39. become more powerful, feature laden, and sport ever greater degrees of
  40. multimediality, the are going to suck up CPU even more.
  41.  
  42. solman> When running those we are also likely running several background
  43. solman> tasks which allows parallelization.
  44.  
  45. Precisely, this is the macro level parallelism that I was thinking of,
  46. which again usually resolves in not more than 2-4 multiprogramming.
  47.  
  48. solman> In the case of a database, I would not expect it to be processor
  49. solman> limited.
  50.  
  51. I used to think like that too, but I was disillusioned. Many DBMSes
  52. (save for the high volume transaction oriented ones, which are very well
  53. suited to highly parallel machines) seem to be significantly CPU bound.
  54. Things like acces path planning, searching hash tables, and so on take
  55. an heavvy toll. 
  56.  
  57. solman> I would think that its performance would be dependent
  58. solman> on the bandwidth and latency between processor and memory.
  59.  
  60. Many CPU bound programs nowadays have become essentially memory limited,
  61. that's agreed. But this should not stop us from seeking for even faster
  62. CPUs, then somebody will have to come up with faster memory :-).
  63.  
  64. solman> In the case of compilers, I have only seen the very simple
  65. solman> compilers that you might find in a college textbook, so I don't
  66. solman> know what is actually used in real life, but they look very
  67. solman> parallelizable.
  68.  
  69. On a micro level, I am skeptical; there are clearly stretches of code
  70. that can be micro parallelized, even vectorized (flow analysis has been
  71. vectorized in some Cray compilers, as it is about sweeping boolean
  72. matrixes), but overall the processing mustr be sequential. It also
  73. depends on the language; for example in C it is conceivable that every
  74. function in a source file be compiled in parallel. But this I would
  75. regard as macro level parallelism.
  76.  
  77. solman> At any rate, I would claim that improvements in processor
  78. solman> performance should only be concerned with apps which are
  79. solman> presently processor limited, and many of these general purpose
  80. solman> codes just aren't.
  81.  
  82. Uhm, memory is so cheap that many "general purpose" applications
  83. nowadays can be made entirely core resident, and a core resident program
  84. is 100% CPU bound.  for example I see most compiles on my machine are
  85. CPU bound; except for reading in the source and writing out the code
  86. there is no IO activity whatsoever.
  87. --
  88. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  89.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  90.   alle orecchie del suo divino protettore, il dio della barzelletta
  91.