🚀 go-pugleaf

In article <PCG.92Dec11162630@aberdb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo Grandi) writes:
|> On 10 Dec 92 03:17:36 GMT, bradc@ferris.cray.com (Bradley R. Carlile) said:
|> 
|> pcg> as far as I can see, 6 instruction issue per cycle is virtually
|> pcg> pointless. The *limit* of superscalarity present in general purpose						 ^^^^^^^^^^^^^^^
|> 
|> Note the "general purpose"; if the codes exhibit high regularity in data
|> access patterns then they are no longer "general purpose" codes, at
|> least in my understanding of that term, which encompasses things like
|> editors, databases, compilers, word processors, spreadsheets, ...

In how many of these examples are we actually concerned with processor
performance? In editors and word processors we certainly aren't. When
running those we are also likely running several background tasks which
allows parallelization. In the case of a database, I would not expect
it to be processor limited. I would think that its performance would
be dependent on the bandwidth and latency between processor and memory.
The same goes for spreadsheets. In the case of compilers, I have only
seen the very simple compilers that you might find in a college textbook,
so I don't know what is actually used in real life, but they look very
parallelizable.

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


Jason W. Solinsky