如何从开销中计算高速缓存大小?
我现在一直在寻找很多时间(超过3天)没有运气。也许你们中的一个人可以告诉我如何解决。
认为您的计算机具有16位大小地址和一个字节可寻址内存。该缓存是2条设定缔合映射,写下策略和完美的LRU替代策略。缓存的开销为4352位。块的大小是多少?
很少有资源谈论开销,而我发现的资源只与总高速缓存大小相关。问题是我只知道如何使用#Blocks或至少使用正确定义的地址字段来计算缓存大小(由于我无法计算标签的大小,因此无法处理此问题。) 。
任何帮助将不胜感激。
I've being looking for this for a lot of time now (over 3 days) without luck. Maybe one of you guys can tell me how can I solve it.
Consider you have a computer with a 16-bit size address and a byte addressable memory. The cache is 2-way set-associative mapped, write-back policy and a perfect LRU replacement strategy. Cache has an overhead of 4352 bits. What's the size of the block?
Very few resources talk about overhead and the ones I've found only relate it to total cache size. The problem is I only know how to calculate cache size with #blocks or at least with the fields of the address properly defined (which I have not being able to do for this problem since I can't calculate the size of the tag.).
Any help would be appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
因此,这是我阅读以下问题的方式:
开销位是不计入被缓存的实际数据的位。 它们是跟踪缓存的维护状态的位,并帮助缓存命中,写回和驱逐策略。 以某种方式查看它,如果一个字节被缓存(8位)在缓存中有多少个非数据位,以帮助管理它(或至少对于所有实际数据位在那里)。
这是数学上的,所以我希望我没有犯错,但是即使我也许您可以通过推理看待自己的方式。
让我们获取一些其他信息:
写下策略意味着缓存需要为每个数据块存储“脏”信息:肮脏是1位:是的,肮脏的-or-否,清洁。
对于2向套件的关联缓存,“完美” LRU算法也是1位(是:第一个块-or-否:第二块),但是每个索引位置的1位成本(即每行) - 不是每个块是每个索引两个块。
我们不知道是否有一个有效的位,这也是每个数据块,但是我在课程中看到的大多数缓存都有有效的位,因此我们可能会假设他们拥有它。
最后,有标签位的标签位:但是,在考虑索引位和块偏移位后,地址空间位剩下许多位。
因此,开销的公式可能是:
位于位的开销=索引位置 *(1 x lru bit + block开销位),
其中块上的头顶位= 2 [方式]
我们还知道标签位=地址空间位 - 索引位 - 块位
,因此我们有:
4352 [bits in bits in Bits] =索引位置 *(1 + 2 *(2 + tag lits))
- 和 -
tag bits =地址空间位 - 索引位 - 块偏移位
- 和 -
索引位置= 2 索引位
- 和 -
我们还知道,标签,索引和块偏移位的数量必须是一个整数(无位分数)。
因此,我们可以通过替换来开始减少这两个公式:
4352 =索引位置 *(1 + 2 *(2 +地址空间位 - 索引位 - 索引位 - 块位 - 块位)
也通过:
4352 = 2 index lit /sup> *(1 + 2 *(2 + 16-索引位 - 块位)
求解块位我们有:
- ((4352/2 index bits -1)/2-18 +索引位)=块位,
我不知道如何直接数学地解决这个问题,鉴于变量必须是整数必须是整数,因此,只需直接求解/搜索不同的值:
如果索引位是7公式,块位是分数的,因此,
索引位为9,则块位是分数,因此不起作用。
如果 ,除:
如果索引位为8,则通过此公式,块位为2,因此:
16 =标签位 + 8 + 2,表示标记位为6,索引位为8,而块偏移为2。
由于块偏移为 2 然后,块大小为2 2 。
So, here's how I read this question:
Overhead bits are the bits that don't count toward the actual data that is being cached. They are bits that track maintenance state of the cache, and help the cache implement hits, write back, and eviction policy. To some way of looking at it, if one byte is being cached (8 bits) how many non-data bits are in the cache to help manage that (or at least for all the actual data bits how many non-data/overhead bits are there).
This is mathematical, so I hope I haven't made an error, but even if I have maybe you can see your way through the reasoning.
Let's derive some additional information:
A write-back policy means the cache needs to store "dirty" information for each data block: dirty is 1-bit: yes, dirty -or- no, clean.
For 2-way set associative cache, a "perfect" LRU algorithm is also 1 bit (yes: first block -or- no: second block) but this 1 bit costs per index position (i.e. per line) — not per block as there are two blocks per index.
What we don't know is if there is a valid bit, which would also be per data block, but most caches I see in coursework have the valid bits, so we might assume they have it.
And lastly, there's the tag bits where tag bits are: however many bits are leftover in the address space bits after accounting for index bits and block offset bits.
So, a formula for overhead might be:
overhead in bits = index positions * (1 x LRU bit + block overhead bits)
where block overhead bits = 2 [ways] * (1 x Dirty bit + 1 x Valid bit + tag bits)
We also know that tag bits = address space bits - index bits - block bits
So, we have:
4352 [overhead in bits] = index positions * (1 + 2 * (2 + tag bits))
-and-
tag bits = address space bits - index bits - block offset bits
-and-
index positions = 2index bits
-and-
We also know that the number of tag, index, and block offset bits has to be an integer (no fractions of bits).
So, we can begin to reduce those two formulas by substituting:
4352 = index positions * (1 + 2 * (2 + address space bits - index bits - block bits)
by reduction also then:
4352 = 2index bits * (1 + 2 * (2 + 16 - index bits - block bits)
Solving for block bits we have:
-((4352/2index bits - 1)/2 - 18 + index bits) = block bits
I don't know how to solve this directly mathematically, given the constraint that the variables must be integers, so, instead of solving directly, simply try/search different values:
If index bits is 7 then by this formula, block bits is fractional, so that doesn't work.
If index bits is 9 then by this formula, block bits is fractional, so that doesn't work.
No other values between 0 and 16 result in an integer number of bits, except:
If index bits is 8 then by this formula, block bits is 2, so:
16 = tag bits + 8 + 2, meaning tag bits is 6, index bits is 8, and block offset is 2.
Since block offset is 2 then block size is 22.