缓存内存:标签和索引有什么区别?

发布于 2025-02-13 22:58:39 字数 108 浏览 0 评论 0原文

我读了很多文章,并观看了解释缓存内存概念的视频,但我仍然无法获得地址格式中的索引和标签之间的区别。他们都说我们需要索引,因为否则多个位置将被放置在缓存中的同一位置。但是我不明白。有人可以解释吗? 谢谢。

I read a lot of articles and watched videos explaining the concept of cache memory but I still can't get what the difference is between an index and a tag in the address format. They all say that we need an index because otherwise multiple locations would get hashed to the same location within the cache. But I don't understand. Can someone please explain?
Thank you.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

萌化 2025-02-20 22:58:39

一个简单数字的地址,通常是一个无符号整数:

+---------------------------+
|          address          |
+---------------------------+

相同的地址(相同的总数)被缓存分解为零件的部分称为字段:

+----------------------------+
|    tag    | index | offset |
+----------------------------+

对于任何给定的缓存,标签宽度,索引宽度和偏移宽度为在位且固定,对于任何给定的地址,每个字段当然都有一个我们可以确定的值,因为我们知道给定缓存的地址和宽度。

Caches存储在称为块的块中的主内存的复制。 要查找某些地址的块地址,请按原样保留其标签和索引位,但将块偏移位设置为零。


假设有两个地址:A和B.  A具有标签,索引和偏移,B具有标签,索引和偏移。

我们想知道A和B是否匹配了内存块的水平 - 这意味着我们关心Tag&索引位匹配,但与偏移位无关。

您可以从上面看到两个地址可能不同,但具有相同的索引 - 许多地址将共享相同的索引,但具有不同的标签或不同的偏移位。

现在,假设B是一个已知被缓存的地址。 这意味着B的内存块和B的索引在缓存中。 整个块都在缓存中,所有块都带有相同的标签&索引和任何可能的偏移位。

假设A是该程序想要访问的某个地址。 缓存的工作是确定a和b是否参考相同的内存块,如果这样,则b在缓存中,访问a是在缓存中的访问,而如果a和b不参考相同的访问内存块,然后在缓存中有一个错过。

caches采用阵列的概念。 他们将索引位置用于数组的元素,以简化其操作。 一个简单的(直接映射)缓存将在数组中的每个索引位置存储一个块(其他缓存将在数组中的每个索引位置存储一个以上的块:这是指cache的集合关联级别,数量“ “,如2路或4路等。)。 要找到所需的元素,我们需要查看缓存。 这是通过采用A索引位置并将其用作缓存数组中的索引来完成的。 如果该元素已经有一个用于地址B的块,并且存储的B标签与A相同,则索引位置和标签都匹配 - 索引匹配 - 因为我们在正确的位置查看,并且标签匹配,因为Cache Stores B的标签,我们拥有所有SO可以将A的标签与B的标签进行比较。

这样的缓存永远不会将块存储在索引位置的地址与其地址的索引位置值不同。 因此,只有一个索引位置可以查看以查看与地址有关的块是否存储。


他们都说我们需要一个索引,因为否则多个位置将被放置到缓存中的同一位置

在缓存体系结构中,索引大小为0位宽。  nbsp;这意味着,无论实际地址如何,所有地址都存储在同一索引位置。 例如缓存是“完全关联的”,并且不使用索引字段(或索引字段的宽度为零)。

索引的好处(当存在缓存体系结构中)是硬件的简化:它只需要查看存储在A索引上的块,而永远不要在存储在缓存中的其他索引上的块。

不使用索引的好处是,一个地址永远不会仅仅是由于具有相同的索引而驱逐另一个地址。完全关联的缓存将受到较少的缓存。

An address as a simple number, usually taken as an unsigned integer:

+---------------------------+
|          address          |
+---------------------------+

The same address — the same overall number — is decomposed by the cache into piece parts called fields:

+----------------------------+
|    tag    | index | offset |
+----------------------------+

For any given cache, the tag width, index width, and offset width are in bits and are fixed, and, for any given address, each field, of course, has a value we can determine given that we know the address and the widths of the fields for the given cache.

Caches store replication of main memory in chunks called blocks.  To find the block address of some address, keep its tag and index bits as is, but set the block offset bits to zeros.


Let's say there are two addresses: A and B.  A has a tag, index and offset, as does B have a tag, index, and offset.

We want to know if A and B match to the level of the block of memory — which means we care about tag & index bits matching, but not about offset bits.

You can see from the above that two addresses can be different yet have the same index — many addresses will share the same index yet have different tag or different offset bits.

Now, let's say that B is an address known to be cached.  That means that the block of memory for B's tag and B's index is in the cache.  The whole block is in the cache, which is all address with the same tag & index, and any possible offset bits.

Let's say that A is some address the program wants to access.  The cache's job is to determine if A and B refer to the same block of memory, if so then since B is in the cache, access of A is a hit in the cache, while if A and B don't refer to the same block of memory, then there is a miss in the cache.

Caches employ a notion of an array.  They use the index positions for the elements of the array, to simplify their operation.  A simple (direct mapped) cache will have a block stored at each index position in the array (other caches will have more than one block stored at each index position in the array: this refers to the cache's set associativity level, number of "ways", as in 2-way or 4-way, etc..).  To find a desired element, A, we need to look in the cache.  This is done by taking A's index position and using it as the index in the cache array.  If the element already there has a block for address B, and B's tag stored there is the same tag value as A's, then both index position and tags match — index matches because we looked in the right place, and tags match because the cache stores B's tag and we have all of A so can compare A's tag with B's tag.

Such a cache will never store the block for an address at an index position different than the index position value for its address.  So, there is only one index position to look at to see if the cache stores the block associated with an address, A.


They all say that we need an index because otherwise multiple locations would get hashed to the same location within the cache

There is a degenerate case in cache architecture where the index size is 0 bits wide.  This means that regardless of the actual address, A, all addresses are stored at the same one index position.  Such as cache is "fully associative" and does not use the index field (or the index field has zero width).

The benefit of the index (when present in the cache architecture) is a simplification of the hardware: it has to only look at blocks stored at the index of A, and never at blocks stored at other indexes within the cache.

The benefit of not using an index is that one address will never evict another merely due to having the same index; fully associative caches are subject to less cache thrashing.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文