🚀 go-pugleaf

On 21 Dec 92 13:45:31 GMT, solman@athena.mit.edu (Jason W Solinsky) said:
Nntp-Posting-Host: m4-035-4.mit.edu

solman> (Piercarlo Grandi) writes:

pcg> as far as I can see, 6 instruction issue per cycle is virtually
pcg> pointless. The *limit* of superscalarity present in general purpose
pcg>						 	 ^^^^^^^^^^^^^^^

pcg> Note the "general purpose"; if the codes exhibit high regularity in
pcg> data access patterns then they are no longer "general purpose"
pcg> codes, at least in my understanding of that term, which encompasses
pcg> things like editors, databases, compilers, word processors,
pcg> spreadsheets, ...

solman> In how many of these examples are we actually concerned with
solman> processor performance? In editors and word processors we
solman> certainly aren't.

How innocent! I use both GNU Emacs and Microsoft Word, and they are both
inconsiderate eaters of CPU time, not to mention TeX. The latter eats up
about 10 million instructions per page. As editors and word processors
become more powerful, feature laden, and sport ever greater degrees of
multimediality, the are going to suck up CPU even more.

solman> When running those we are also likely running several background
solman> tasks which allows parallelization.

Precisely, this is the macro level parallelism that I was thinking of,
which again usually resolves in not more than 2-4 multiprogramming.

solman> In the case of a database, I would not expect it to be processor
solman> limited.

I used to think like that too, but I was disillusioned. Many DBMSes
(save for the high volume transaction oriented ones, which are very well
suited to highly parallel machines) seem to be significantly CPU bound.
Things like acces path planning, searching hash tables, and so on take
an heavvy toll. 

solman> I would think that its performance would be dependent
solman> on the bandwidth and latency between processor and memory.

Many CPU bound programs nowadays have become essentially memory limited,
that's agreed. But this should not stop us from seeking for even faster
CPUs, then somebody will have to come up with faster memory :-).

solman> In the case of compilers, I have only seen the very simple
solman> compilers that you might find in a college textbook, so I don't
solman> know what is actually used in real life, but they look very
solman> parallelizable.

On a micro level, I am skeptical; there are clearly stretches of code
that can be micro parallelized, even vectorized (flow analysis has been
vectorized in some Cray compilers, as it is about sweeping boolean
matrixes), but overall the processing mustr be sequential. It also
depends on the language; for example in C it is conceivable that every
function in a source file be compiled in parallel. But this I would
regard as macro level parallelism.

solman> At any rate, I would claim that improvements in processor
solman> performance should only be concerned with apps which are
solman> presently processor limited, and many of these general purpose
solman> codes just aren't.

Uhm, memory is so cheap that many "general purpose" applications
nowadays can be made entirely core resident, and a core resident program
is 100% CPU bound.  for example I see most compiles on my machine are
CPU bound; except for reading in the source and writing out the code
there is no IO activity whatsoever.
--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta