tdonahue@bbn.com (Tim Donahue) (02/27/91)
In article <46046@mips.mips.COM>, mash@mips (John Mashey) writes: > <stuff about additional area for 64-bit MPU deleted> >... >Now, the caches together are about 14% also, so maybe we could have >doubled one of the caches, which would have been nice. >... OK, John, given the perceived market for the R4000, if you had to choose which cache to double in size, which would you choose, and why? >-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> Cheers, Tim Timothy P. Donahue Operating Systems Development Group BBN Advanced Computers, Inc. 10 Fawcett Street Cambridge, MA 02138 (617) 873-6000 tdonahue@bbn.com --
mash@mips.com (John Mashey) (03/06/91)
In article <62981@bbn.BBN.COM> tdonahue@bbn.com (Tim Donahue) writes: >In article <46046@mips.mips.COM>, mash@mips (John Mashey) writes: >> <stuff about additional area for 64-bit MPU deleted> >>... >>Now, the caches together are about 14% also, so maybe we could have >>doubled one of the caches, which would have been nice. >>... > >OK, John, given the perceived market for the R4000, if you had to choose >which cache to double in size, which would you choose, and why? Well, as I looked at the chip later, it was 4% difference, so maybe we could have increased the I-cache by 1.5X, and at this size, it would have been the I-cache, for sure. For the kinds of mixes we worry about, the reasoning for this is: at 8KB each, the I-cache usually has a higher miss-rate than the D-cache, but more importantly, the slopes of the curves are different, i.e., doubling the I-cache yields more performance than doubling the D-cache, until you get to the point where you've got most of what you're going to get from the I-cache, and then, doubling the D-cache lets you run bigger problems faster. At 16KB each, it would have been a closer call, and if you had 32K or bigger, you'd probably double the data cache, assuming you had the space, and that none of this distorted the layout too much... This is the general reasoning; there are plenty of numbers, but I don't think we're quite yet willing to publish them. Of course, if linear algebra & such were highest priority, then you'd probably keep the I-cache small and put the silicon into D-cache. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94086