SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Politics : Formerly About Advanced Micro Devices -- Ignore unavailable to you. Want to Upgrade?


To: Dan3 who wrote (92909)2/13/2000 8:03:00 PM
From: Scumbria  Respond to of 1574483
 
Dan,

That was basically the point that I was trying to make. The 16-way cache gives up 12.5% (2/16ths) of its useful capacity duplicating addresses in the 2-way cache - but the remainder of the 16-way cache acts as a psuedo victim cache, maintaining addresses cast out of the 2-way cache.

Not as effective as a true victim cache, but possibly easier to implement?


The problem is that most (>80%) of the 16 way L2 cache is redundant with the L1, and thus wasted space. A victim cache has almost no redundancy and is quite simple to implement. It is actually simpler than a standard cache because cache writes are not timing critical.

Scumbria



To: Dan3 who wrote (92909)2/13/2000 11:34:00 PM
From: Scumbria  Read Replies (1) | Respond to of 1574483
 
Dan,

The 16-way cache gives up 12.5% (2/16ths) of its useful capacity duplicating addresses in the 2-way cache - but the remainder of the 16-way cache acts as a psuedo victim cache, maintaining addresses cast out of the 2-way cache.

I'm starting to understand how you are thinking. The piece of information you aren't addressing is that in the 16 way cache, 8 times as many addresses map into a particular cache index. Most of the remaining 14/16 of the cache set will be filled with addresses that are also resident in the 2 way cache (in different indexes.)

If you wish, I could print some simple C code to show the address mapping and why there is so much overlap.

Scumbria