Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!vsi1!wyse!stevew
From: stevew@wyse.wyse.com (Steve Wilson xttemp dept303)
Newsgroups: comp.arch
Subject: Re: How to use silicon (was Re: Intel/MIPS Dhrystone ratio)
Keywords: Comlexity, speed, risc, cisc
Message-ID: <2160@wyse.wyse.com>
Date: 21 Mar 89 01:30:44 GMT
References: <37196@bbn.COM> <1989Mar16.190043.23227@utzoo.uucp> <24889@amdcad.AMD.COM> <355@bnr-fos.UUCP>
Sender: news@wyse.wyse.com
Reply-To: stevew@wyse.UUCP (Steve Wilson xttemp dept303)
Organization: Wyse Technology
Lines: 23

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.