🚀 go-pugleaf

In article <PCG.92Dec23144916@decb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>On 21 Dec 92 13:45:31 GMT, solman@athena.mit.edu (Jason W Solinsky) said:
>
>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.

I disagree with this distinction.  A core resident program can be very
seriously *memory* bound if the processor is spending most of its time
locked down waiting for cache misses to be filled.   Many "cpu-bound"
programs spend half or more of their time in this state, and it is very
easy to accidentally build a program which spends 90% of its time
waiting for cache line refills.

Common applications such as text editting of large files (i.e. files
significantly larger than cache) could benefit considerably from
decreasing cache latency and would often benefit from having wider
memory-to-cache buses.

Although I don't think it was ever done, the world's fastest text
editor could probably have been written for the ETA-10, which had a
bewildering variety of instructions for copying and searching chunks of
its bit-addressable memory at vector speeds.   The Cray machines could
be competitive, but the lack of byte addressability makes working with
text awkward and relatively slow.
-- 
--
John D. McCalpin                        mccalpin@perelandra.cms.udel.edu
Assistant Professor                     mccalpin@brahms.udel.edu
College of Marine Studies, U. Del.      John.McCalpin@mvs.udel.edu