每个程序员都应该了解 CPU 高速缓存.pdfVIP

每个程序员都应该了解的 CPU 高速缓存 [编者按 ：这是Ulrich Drepper 写“程序员都该知道存储器”的第二部。那些没有读过第一部 的读者可能希望从这一部 开始。这本书写的非常好 ，并且感谢Ulrich 授权我们出版。 一点说明 ：书籍出版时可能会有一些印刷错误，如果你发现，并且想让它在后续的出版中更正，请将意见发邮件到 lwn@ ，我们一定会更正 ，并反馈给Ulrich 的文档副本 ，别的读者就不会受到这些困扰。] 现在的 CPU 比 25 年前要精密得多了。在那个年代 ，CPU 的频率与内存总线的频率基本在同一层面上。内存的访 问速度仅比寄存器慢那么一点点。但是 ，这一局面在上世纪90 年代被打破了。CPU 的频率大大提升 ，但内存总线的频 率与内存芯片的性能却没有得到成比例的提升。并不是因为造不出更快的内存 ，只是因为太贵了。内存如果要达到目前 CPU 那样的速度 ，那么它的造价恐怕要贵上好几个数量级。 如果有两个选项让你选择 ，一个是速度非常快、但容量很小的内存 ，一个是速度还算快、但容量很多的内存 ，如 果你的工作集比较大 ，超过了前一种情况，那么人们总是会选择第二个选项。原因在于辅存(一般为磁盘)的速度。由于 工作集超过主存 ，那么必须用辅存来保存交换出去的那部分数据，而辅存的速度往往要比主存慢上好几个数量级。 好在这问题也并不全然是非甲即乙的选择。在配置大量 DRAM 的同时 ，我们还可以配置少量SRAM。将地址空间的某 个部分划给 SRAM，剩下的部分划给 DRAM。一般来说 ，SRAM 可以当作扩展的寄存器来使用。 上面的做法看起来似乎可以 ，但实际上并不可行。首先 ，将 SRAM 内存映射到进程的虚拟地址空间就是个非常复 杂的工作 ，而且，在这种做法中，每个进程都需要管理这个SRAM 区内存的分配。每个进程可能有大小完全不同的 SRAM 区，而组成程序的每个模块也需要索取属于自身的 SRAM，更引入了额外的同步需求。简而言之 ，快速内存带来的好处 完全被额外的管理开销给抵消了。 基于以上的原因 ，我们不将SRAM 放在 OS 或用户的控制下 ，而是将它交由处理器来使用和管理。在这种模式下 ， SRAM 用于对存储在主存中、即将使用的数据进行临时拷贝(换句话说 ，缓存)。这种做法的依据是程序代码和数据具有 时间局部性和空间局部性。也就是说 ，在一段较短的时间内，同一份代码和数据有很大的可能被重复使用。对代码来说 ， 是循环 ，即同一段代码被反复执行(完美的 空间局部性)。对数据来说 ，是反复访问某一小片区域中的数据。即使在短时 间内对内存的访问并不连续 ，但仍有很大可能在不长的时间内重复访问同一份数据( 空间局部性)。这两个局部性是我们 理解 CPU 高速缓存的关键。 我们先用一个简单的计算来展示一下高速缓存的效率。假设 ，访问主存需要200 个周期 ，而访问高速缓存需要15 个周期。如果使用 100 个数据元素 100 次，那么在没有高速缓存的情况下 ，需要2000000 个周期 ，而在有高速缓存、 而且所有数据都已被缓存的情况下 ，只需要168500 个周期。节约了 91.5%的时间。 用作高速缓存的 SRAM 容量比主存小得多。以我的经验来说 ，高速缓存的大小一般是主存的千分之一左右(目前一般是 4GB 主存、4MB 缓存)。这一点本身并不是什么问题。只是 ，计算机一般都会有比较大的主存，因此工作集的大小总是 会大于缓存。特别是那些运行多进程的系统 ，它的工作集大小是所有进程加上内核的总和。 处理高速缓存大小的限制需要制定一套很好的策略来决定在给定的时间内什么数据应该被缓存。由于不是所有数 据的工作集都是在完全相同的时间段内被使用的 ，我们可以用一些技术手段将需要用到的数据临时替换那些当前并未使 用的缓存数据。这种预取将会减少部分访问主存的成本 ，因为它与程序的执行是异步的。所有的这些技术将会使高速缓 存在使用的时候看起来比实际更大。我们将在 3.3 节讨论这些问题。 我们将在第 6 章讨论如何让这些技术能很好地帮助 程序员 ，让处理器更高效地工作。 .1 高速缓存的位置 在深入介绍高速缓存的技术细节之前 ，有必要说明一下它在现代计算机系统中所处的位置。