Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!voder!apple!north
From: north@Apple.COM (Donald N. North)
Newsgroups: comp.arch
Subject: Re: CPU chip cache sizes, was Re: Harvard Architecure
Message-ID: <7672@apple.Apple.Com>
Date: 14 Mar 88 17:50:21 GMT
References: <8803011911.AA06922@decwrl.dec.com> <3460011@hpsrla.HP.COM> <1071@PT.CS.CMU.EDU> <5009@nsc.nsc.com> <1853@winchester.mips.COM>
Reply-To: north@apple.UUCP (Donald N. North)
Organization: Apple Computer, Inc.
Lines: 27
Keywords: 68030 performance d-cache

In article <1853@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes:
>I recall there was speculation when the 68030 was announced that the
>D-cache might actually cost you performance in general applications,
>Do you (or anybody else) have any good data on a 256-byte cache with
>16 16-byte lines? (i.e., the 68030 D-cache)

Having had some '030 experience as of late, I have found that (in real working
hardware) the D-cache is always a 'win', even though it is small by most
standards.  I have yet to find a benchmark (Dhrystone, any others of the small
integer class) or some real application code in which the performance is less
when the cache is enabled than disabled.  The typical performance improvement
ranges from a low of 5% to a high of 25%, 'average' for larger applications
appears to be about 20%.

In looking at the cache organization (direct mapped, 16-16 byte lines) one could
construct a sequence of references (accessing data locations exactly 256 bytes
apart, for example) that causes thrashing in particular cache lines.  This is a
problem in all direct mapped caches, and one would think it to be especially
severe with such a few number of entries (16 in the '030s case).  I suspect 
this is one reason for the relatively low performance improvement figures; the
other is that the cache is just too small to be 'really' useful except in limited
situations.  Two that come immediately to mind are pushing stack arguments that
are then accessed relatively soon, and accesses to local stack storage.

Don North   -----   Apple Computer, Inc.   -----   Advanced Technology Group
UUCP: {voder,nsc,dual,sun}!apple!north                CSNET: north@apple.com
{{ Facts are facts,  but any opinions expressed are my own,  and *do not* }}
{{ represent any viewpoint, official or otherwise, of Apple Computer, Inc.}}