Path: utzoo!utgpu!bnr-vpa!bnr-fos!bnr-public!schow
From: schow@bnr-public.uucp (Stanley Chow)
Newsgroups: comp.arch
Subject: Re: How to use silicon (was Re: Intel/MIPS Dhrystone ratio)
Keywords: Comlexity, speed, risc, cisc
Message-ID: <361@bnr-fos.UUCP>
Date: 22 Mar 89 00:09:27 GMT
References: <355@bnr-fos.UUCP> <2160@wyse.wyse.com>
Sender: news@bnr-fos.UUCP
Reply-To: schow@bnr-public.UUCP (Stanley Chow)
Organization: Bell-Northern Research, Ottawa, Canada
Lines: 56

In article <2160@wyse.wyse.com> stevew@wyse.UUCP (Steve Wilson xttemp dept303) writes:
>In article <355@bnr-fos.UUCP> schow@bnr-public.UUCP (Stanley Chow) writes:
>> ...lotsa stuff deleted.
>> 
>>Caches (especially Data-cache) top out very easily. For many Unix-box
>>type application, we have already reached the point of vastly-diminished
>>return. Adding more cache won't bring your performance up.  (Or I could
>>talk about our application where the diminishing return starts *before*
>>you start adding cache.)
>
>Before you start giving away the on-chip caches, lets get them to a respectable
>size first.  The average on-chip cache we are seeing now is 512 to 1K bytes
>for both D and I.  Hit rates of 80% for the I cache and 40-50% for the D
>cache are prevalent.  We still have a way to go in this arena from what
>I can see. (Yeah, I know the 88200 has 16K, but it isn't the same chip
>as the 88100...;-)
>
>Caches are a proven method of keeping the off-chip accesses to a minimum
>and we still haven't been able to put really large caches on the same
>chip as the CPU.  Let's really saturate this path first...
>
>Steve Wilson
>
>These are my opinions, not those of my employer. 

Different people have different ideas of what a "respectable" cache is.
Most Unix-type programs/filters/... are pretty happy with small caches
(by small, I mean <64K). This is of course how RISC (and CISC) workstations
get their performance.

Some one mentioned (in an article about vector processing and the i860,
I think) that the 32 Meg Cache in an ETA machine is not enough for some
applications.

Realistically, I do not foresee on-chip cache being expanded to a megabyte
anytime soon. Going from 512 to 4K to 16K to 64K will buy performance for
some (even many) applications but other applications will still be killed
by the miss-rate.

I am suggesting that instead of spending the silicon real-estate on bigger
caches, other options may be open. In particular, I am suggesting that
more complex instructions can be a useful way to decrease band-width 
demand on the cache/memory system. John Mashy talks about the almost
constant band-width needed for a MIP. Caches are a way to up the perceived
band-width of the memory. I am suggesting that silicon can be used to
decrease the demand.


Stanley Chow   ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public
		 (613) 763-2831

Cache? Don't carry it, I use platic money. 

[This way, my employer knows I have to go to conferences and courses
to learn about this stuff. Unfortunately, this means they don't let
me represent them either.]