怎么看cpu缓存

【CSDN 编者按】由于CPU是核心硬件，相信我们在选择CPU的时候都会去关心CPU参数方面，而在CPU核心参数中，我们经常会看到缓存这个参数，那么CPU缓存有什么用呢？随着本文去了解一下吧。

作者 | 神技圈子 责编 | 欧阳姝黎

出品 | CSDN博客

基础知识

首先，大家都知道现在 CPU 的多核技术，都会有几级缓存，现在的CPU会有三级内存（L1，L2， L3），如下图所示。

其中：

L1 缓存分成两种，一种是指令缓存，一种是数据缓存。L2 缓存和 L3 缓存不分指令和数据。

• L1 和 L2 缓存在每一个 CPU 核中，L3 则是所有 CPU 核心共享的内存。
• L1、L2、L3 的越离 CPU 近就越小，速度也就越快，越离 CPU 远，速度也越慢。

再往后面就是内存，内存的后面就是硬盘。我们来看一些他们的速度。

• L1 的存取速度：4 个 CPU 时钟周期
• L2 的存取速度：11 个 CPU 时钟周期
• L3 的存取速度：39 个 CPU 时钟周期
• RAM 内存的存取速度：107 个 CPU 时钟周期

我们可以看到，L1 的速度是 RAM 的 27 倍，L1 和 L2 的存取大小基本上是KB级的，L3 则是MB级别的。例如，Intel Core i7-8700K,是一个 6 核的 CPU，每核上的 L1 是 64KB（数据和指令各32KB）,L2 是 256K，L3 有 2MB。

我们的数据从内存向上，先到 L3，再到 L2，再到 L1，最后到寄存器进行计算。那么，为什么会设计成三层？这里有以下几方面的考虑：

• 物理速度，如果要更大的容量就需要更多的晶体管，除了芯片的体积会变大，更重要的是大量的晶体管会导致速度下降，因为访问速度和要访问的晶体管所在的位置成反比。也就是当信号路径变长时，通信速度会变慢，这就是物理问题。
• 另外一个问题是，多核技术中，数据的状态需要在多个 CPU 进行同步。我们可以看到，cache 和 RAM 的速度差距太大。所以，多级不同尺原由网寸的缓存有利于提高整体的性能。 这个世界永远是平衡的，一面变得有多光鲜，另一方面也会变得有多黑暗，建立多级的缓存，一定就会引入其它的问题。这里有两个比较重要的问题。
• 一个是比较简单的缓存命中率的问题
• 另一个是比较复杂的缓存更新的一致性问题

尤其是第二个问题，在多核技术下，这就很像分布式系统了，要面对多个地方进行更新。

缓存命中

首先，我们需要了解一个术语 Cache Line。缓存基本上来说就是把后面的数据加载到离自己最近的地方，对于 CPU 来说，它是不会一个字节一个字节的加载的。因为这非常没有效率，一般来说都是要一块一块的加载的，对于这样一块一块的数据单位，术语叫“Cache Line”。一般来说，一个主流的 CPU 的 Cache Line 是 64 Bytes(也有的 CPU 用 32Bytes 和 128Bytes),64Bytes也就是 16 个 32 位的数字,这就是 CPU 从内存中捞数据上来的最小数据单位。比如：Cache Line是最小单位（64Bytes），所以先把 Cache 分布多 个Cache Line。比如：L1有 32KB，那么 32KB/64B = 512 个 Cache Line。

缓存需要把内存里的数据放进来，英文叫 CPU Associativity，Cache的数据放置策略决定了内存中的数据会拷贝到 CPU Cache 中的哪个位置上，因为 Cache 的大小远远小于内存，所以，需要有一种地址关联算法，能够让内存中的数据被映射到 Cache 中。这个就有点像内存地址从逻辑地址到物理地址的映射方法。但是不完全一样。

基本上会有以下的一些方法

• 任何一个内存的数据可以被缓存在任何一个 Cache Line 里，这种方法是最灵活的，但是，如果我们要知道一个内存是否存在于 Cache 中。我们就需要进行O(n)复杂度的 Cache 遍历，这是没有效率的。
• 另一种方法，为了降低缓存搜索算法的时间复杂度，我们要使用像 hash table 这样的数据结构，最简单的 hash table 就是“求模运算”。 比如，我们的 L1 Cache 有 512 个 Cache Line,那么公式就是(内存地址 mod 512) *6//www.58yuanyou.com4就可以直接找到所在的Cache地址的偏移了。 但是，这样的方式需要程序对内存地址的访问非常的平均，不然会造成严重 的 冲突。 所以，这成了一个非常理想的情况了。
• 为了避免上述的两种方案的问题，于是就要容忍一定的hash冲突，也就出现了 N-Way 关联。也就是把连续的 N 个 Cache Line 绑成一组，然后，先找到相关的组，然后再在组内找到相关的 Cache Line。这叫 Set Associativity。如下图所示

对于 N-Way 组关联，可能有点不好理解。这里举个例子，并多说一些细节（不然后面的代码你会不能理解），Intel 大多数处理器的L1 Cache都是32KB，8-Way 组相联，Cache Line 是64 Bytes。这意味着

• 32KB 的可以分成，32KB / 64 = 512 条 Cache Line；
• 因为有 8 Way，于是会每一Way 有 512 / 8 = 64 条 Cache Line；
• 于是每一路就有 64 x 64 = 4096 Byts 的内存。

为了方便索引内存地址

• Tag： 每条 Cache Line 前都会有一个独立分配的 24 bits来存的 tag，其就是内存地址的前24bits；
• Index： 内存地址后续的6个bits则是在这一Way的是Cache Line 索引，2^6 = 64 刚好可以索引64条Cache Line；
• Offset： 再往后的6bits用于表示在Cache Line 里的偏移量

索引过程如下图所示：

• 当拿到一个内存地址的时候，先拿出中间的 6bits 来，找到是哪组；

• 然后在这一个8组的cache line中，再进行O(n) ，n=8 的遍历，主是要匹配前24bits的tag。如果匹配中了，就算命中，如果没有匹配到，那就是cache miss，如果是读操作，就需要进向后面的缓存进行访问了。L2和L3同样是这样的算法。而淘汰算法有两种，一种是随机，另一种是LRU。

这也意味着：

• L1 Cache 可映射 36bits 的内存地址，一共 2^36 = 64GB的内存
• 当 CPU 要访问一个内存的时候，通过这个内存中间的6bits 定位是哪个set，通过前 24bits 定位相应的Cache Line。
• 就像一个hash Table的数据结构一样，先是O(1)的索引，然后进入冲突搜索。因为中间的 6bits决定了一个同一个 set，所以，对于一段连续的内存来说，每隔4096的内存会被放在同一个组内，导致缓存冲突。

此外，当有数据没有命中缓存的时候，CPU 就会以最小为 Cache Line 的单元向内存更新数据。当然，CPU 并不一定只是更原由网新64Bytes，因为访问主存实在是太慢了，所以，一般都会多更新一些。好的CPU会有一些预测的技术，如果找到一种 pattern 的话，就会预先加载更多的内存，包括指令也可以预加载。这叫 Prefetching 技术。比如，你在 for-loop 访问一个连续的数组，你的步长是一个固定的数，内存就可以做到 prefetching。

了解这些细节，会有利于我们知道在什么情况下有可以导致缓存的失效。

缓存一致

对于主流的 CPU 来说，缓存的写操作基本上是两种策略

• Write Back： 写操作只在 Cache 上，然后再 flush 到内存上
• Write Through： 写操作同时写到 cache 和内存上。

为了提高写的性能，一般来说，主流的 CPU（如：Intel Core i7/i9）采用的是 Write Back 的策略，因为直接写内存实在是太慢了。

好了，现在问题来了，如果有一个数据 x 在 CPU 第 0 核的缓存上被更新了，那么其它 CPU 核上对于这个数据 x 的值也要被更新，这就是缓存一致性的问题。

一般来说，在 CPU 硬件上，会有两种方法来解决这个问题。

1. Directory 协议。 这种方法的典型实现是要设计一个集中式控制器，它是主存储器控制器的一部分。其中有一个目录存储在主存储器中，其中包含有关各种本地缓存内容的全局状态信息。当单个 CPU Cache 发出读写请求时，这个集中式控制器会检查并发出必要的命令，以在主存和 CPU Cache 之间或在 CPU Cache 自身之间进行数据同步和传输。

因为 Directory 协议是一个中心式的，会有性能瓶颈，而且会增加整体设计的复杂度。而 Snoopy 协议更像是微服务+消息通讯，所以，现在基本都是使用 Snoopy 的总线的设计。

在分布式系统中我们一般用 Paxos/Raft 这样的分布式一致性的算法。而在 CPU 的微观世界里，则不必使用这样的算法。因为 CPU 的多个核的硬件不必考虑网络会断会延迟的问题。所以，CPU 的多核心缓存间的同步的核心就是要管理好数据的状态就好了。

这里介绍几个状态协议，先从最简单的开始，MESI 协议，这个协议跟那个著名的足球运动员梅西没什么关系，其主要表示缓存数据有四个状态： Modified（已修改）, Exclusive（独占的）,Shared（共享的），Invalid（无效的）。

MESI 这种协议在数据更新后，会标记其它共享的 CPU 缓存的数据拷贝为Invalid 状态，然后当其它 CPU 再次 read 的时候，就会出现 cache miss 的问题，此时再从内存中更新数据。从内存中更新数据意味着 20 倍速度的降低。我们能不能直接从我隔壁的 CPU 缓存中更新？是的，这就可以增加很多速度了，但是状态控制也就变麻烦了。还需要多来一个状态：Owner(宿主)，用于标记，我是更新数据的源。于是，出现了 MOESI 协议。

MOESI协议允许 CPU Cache 间同步数据，于是也降低了对内存的操作，性能是非常大的提升，但是控制逻辑也非常复杂。

顺便说一下，与 MOESI 协议类似的一个协议是 MESIF，其中的 F 是 Forward，同样是把更新过的数据转发给别的 CPU Cache 但是，MOESI 中的 Owner 状态 和 MESIF 中的 Forward 状态有一个非常大的不一样—— Owner状态下的数据是 dirty 的，还没有写回内存，Forward 状态下的数据是clean的，可以丢弃而不用另行通知。

需要说明的是，AMD 用 MOESI，Intel 用 MESIF。所以，F 状态主要是针对 CPU L3 Cache 设计的（前面我们说过，L3是所有CPU核心共享的）。

程序性能

了解了www.58yuanyou.com我们上面的这些东西后，我们来看一下对于程序的影响。

示例一

首先，假设我们有一个64M长的数组，设想一下下面的两个循环：