Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!apple!vsi1!wyse!mips!earl@wright.mips.com
From: earl@wright.mips.com (Earl Killian)
Newsgroups: comp.arch
Subject: Re: i860 CPU information
Keywords: i860 N10 cache
Message-ID: <15037@wright.mips.COM>
Date: 10 Mar 89 17:28:19 GMT
References: <1895@oakhill.UUCP> <21570@shemp.CS.UCLA.EDU>
Sender: earl@mips.COM
Reply-To: earl@wright.mips.com (Earl Killian)
Distribution: usa
Organization: MIPS Computer Systems, Sunnyvale CA
Lines: 28
In-reply-to: marc@oahu.cs.ucla.edu (Marc Tremblay)

In article <1895@oakhill.UUCP> tomj@oakhill.UUCP (Tom Johnson) and
article <21570@shemp.CS.UCLA.EDU>, marc@oahu (Marc Tremblay) discuss
the choice of I-cache and D-cache size on the i860.

The reason that most systems have identical sized caches is just for
simplicity, and secondarily because it is often the best overall
performance choice.  On a large suite of benchmarks you'll find a
large number miss more in the i-cache, and a large number miss more in
the d-cache.  The average results depends on the set of benchmarks
chosen, and on other cache parameters, such as the number of words
refilled on a cache miss.  There is no universal truth.

For example, the M/500 had a 16KB I-cache and 8KB D-cache because its
performance was more I-cache limited.  But if it had a larger cache
refill size, it might have become more D-limited because large refill
works better for I than D.

As for why the i860 D-cache is twice the size of the I-cache, my guess
is a very simple explanation: the D-cache had to be twice as wide in
order to support 128-bit load/store.

I've now simulated i860-style caches on a wide range of programs, and
the size of both caches is a problem, with I-cache more of a
bottleneck.  The overall cpi is in the range of 2.2-2.7, resulting in
>native< MIPS of 12 to 15 at 33.3MHz.  A tad far from "150-mips" eh?
--
UUCP: {ames,decwrl,prls,pyramid}!mips!earl
USPS: MIPS Computer Systems, 930 Arques Ave, Sunnyvale CA, 94086