简体   繁体   English

如何计算缓存开销?

[英]How to Calculate Cache Overhead?

I've been given a problem by my computer architecture professor but it is using some terminology that I cannot find in our textbook. 我的计算机体系结构教授给我一个问题,但它使用的是我在教科书中找不到的某些术语。

Basically, I'm given a cache with the following parameters: 基本上,我为缓存提供了以下参数:

-4KB address space -Byte-addressable memory -Direct-Mapped -2 blocks in cache -4-word blocks -4KB地址空间-可字节寻址的内存-直接映射的-2个块在高速缓存中-4-个字块

I have no problem drawing out this cache and modeling what would happen with various inputs. 我可以毫不费力地绘制出这个缓存并为各种输入建模。 However there is one question I'm being asked: 但是,有人问我一个问题:

"The cache stores overhead information. What percentage of the total cache storage is this overhead?" “缓存存储了开销信息。此开销占缓存总存储量的百分之几?”

I have no idea what this means. 我不知道这是什么意思。 I've been searching "cache overhead" on Google and StackOverflow and I haven't been able to find anything that places those two words together in a helpful context for me. 我一直在Google和StackOverflow上搜索“缓存开销”,但找不到任何可以将这两个词放在一起的有用信息。 I don't see it in my textbook either. 我的教科书中也没有看到它。

Any insight would be greatly appreciated. 任何见识将不胜感激。

Thank You! 谢谢!

I got an answer for the question. 我得到了这个问题的答案。 I'll post it here in case anyone else has trouble. 如果有人遇到麻烦,我会在这里张贴。

Apparently, overhead is a more general term in Computer Science that I'd never heard before, referring to extraneous resources - in this case, bits. 显然,开销是计算机科学中一个更通用的术语,我以前从未听说过,它指的是无关的资源-在这种情况下,是比特。

When referring to cache overhead, the question was referring to bits that are necessary for the cache, but that do not include the data itself. 当提到高速缓存开销时,问题是指向高速缓存所需的位,但不包括数据本身。

In this particular case, the cache included the validity bid, and the tag. 在这种特定情况下,缓存包括有效性出价和标签。 In order to calculate the overhead as a percentage, I had to take the sum of all validity bits and tag bits and divide them by the total cache size. 为了以百分比形式计算开销,我必须将所有有效位和标记位的总和除以总缓存大小。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM