🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: sci.electronics
Article #20904

Re: Designing for the FHF (was Re: Proprietary hardware)

#20904
From: Don Winsor
Date: Mon, 20 Mar 1989 22:07
43 lines
3040 bytes
In article <18204@gatech.edu> ken@gatech.UUCP (Ken Seefried iii) writes:
>Ummmm...you need to learn a little more about caches.  You can get the
>same hit-rate with a 64K, 2-way cache as a 128K, direct-mapped cache
>(93%).  Bigger is not nessesarily better.  In any case, have you
>prices building a cache like that lately?  Talk about sticker shock...

But hit rate isn't the whole story!  For large caches, overall
performance is more sensitive to the cache access time on a cache
hit than to the cache hit rate.  Practical implementations of
direct-mapped caches are significantly faster than set-associative
caches.  The main reason for this is that a set-associative cache
must have a multiplexor to select the outputs from the appropriate
bank.  A direct-mapped cache does not need any such multiplexor;
thus a significant delay in the critical path is eliminated.
Another advantage of direct-mapped caches is that they are
significantly cheaper that set-associative ones of the same size.

A thorough investigation of this is presented in the article:
Mark D. Hill, "A Case for Direct-Mapped Caches", Computer, volume 21,
number 12, December 1988, pages 25-40, IEEE Computer Society.

Hill shows that for cache sizes above a certain crossover point,
direct-mapped caches will almost always outperform set-associative
caches of the same size.  Depending on the main memory speed and
other details of the cache organization, the crossover point was
found to occur at cache sizes from 8 Kbytes to 64 Kbytes.

Note that Sun uses direct-mapped caches in their highest performance
servers; the Sun 3/280 uses a 64 Kbyte direct mapped cache and the
Sun 4/280 uses a 128 Kbyte direct mapped cache.  Why?  I suspect
it's because they were smart enough to realize that cache access
time was a critical factor limiting performance, and a significantly
faster access time was well worth a tiny penalty in miss ratio.

My personal preference for a new design is for separate instruction
and data caches, each 64 Kbytes (or larger if cost permits) and
direct mapped.  With some of the new cache controller chips appearing
on the market, such a creature shouldn't be too horribly expensive.

Don Winsor
Department of Electrical Engineering and Computer Science
University of Michigan, Ann Arbor, Michigan
don@eecs.umich.edu
Technical Details
Message-ID: <1554@zippy.eecs.umich.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!don
References: <2140@cpoint.UUCP> <3743@stiatl.UUCP> <1204@naucse.UUCP> <1410@husc6.harvard.edu> <18167@gatech.edu> <4899@cbnews.ATT.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!don
From: don@zippy.eecs.umich.edu (Don Winsor)
Newsgroups: sci.electronics,comp.periphs
Subject: Re: Designing for the FHF (was Re: Proprietary hardware)
Keywords: schematics, repair information, free software foundation,
Message-ID: <1554@zippy.eecs.umich.edu>
Date: 20 Mar 89 22:07:22 GMT
References: <2140@cpoint.UUCP> <3743@stiatl.UUCP> <1204@naucse.UUCP> <1410@husc6.harvard.edu> <18167@gatech.edu> <4899@cbnews.ATT.COM>
Sender: news@zippy.eecs.umich.edu
Reply-To: don@zippy.eecs.umich.edu (Don Winsor)
Organization: University of Michigan EECS Dept. Ann Arbor
Lines: 43
UUCP-Path: ihnp4!umich!zippy!don