3.5.3. cache的配置

cache在与 HT 及处理器核的关系中的位置并不在程序开发者的控制之下。但程序开发者能够决定执行绪要在何处执行，于是cache如何与使用的 CPU 共处就变得很重要。

这里我们不会深入在何时选择哪颗处理器核来执行执行绪的细节。我们只会描述在设置执行绪的亲和性（affinity）时，程序开发者必须要考虑的架构细节。

HT，根据定义，共享暂存器集以外的所有东西。这包含 L1 cache。这里没什么好说的。有趣之处从一个处理器的个别处理器核开始。每颗处理器核至少拥有它自己的 L1 cache。除此之外，现今共有的细节并不多：

• 早期的多核处理器完全不共享cache。
• 之后的 Intel 模型的双核处理器拥有共享的 L2 cache。对于四核处理器，我们必须为由两颗处理器核组成的每一对处理个别的 L2 cache。没有更高层级的cache。
• AMD 的 10h 处理器家族拥有独立的 L2 cache与一个统一式 L3 cache。

在处理器供应商的宣传品中已经写许多关于它们各自的模型的优点。若是由处理器核处理的工作集并不重叠，拥有不共享的cache就有一些优势。这对于单执行绪程序而言非常有用。由于这仍经常是当下的真实情况，因此这种做法并不怎么差。但总是会有一些重叠的。cache都包含通用执行期函式库（runtime library）中最活跃使用的部分，代表有一些cache空间会被浪费。

与 Intel 的双核处理器一样完全共享 L1 以外的所有cache有个大优点。若是在两颗处理器核上的执行绪工作集有大量的重叠，可用的cachememory总量也会增加，工作集也能够更大而不致降低效能。若是工作集没有重叠，Intel 的进阶智慧型cache（Advanced Smart Cache）管理应该要防止任何一颗处理器核独占整个cache。

不过，如果两颗处理器核为了它们各自的工作集使用大约一半的cache，也会有一些冲突。cache必须不断地掂量两颗处理器核的cache使用量，而作为这个重新平衡的一部分而执行的逐出操作可能会选得很差。为了看到这个问题，让我们看看另一个测试程序的结果。

测试程序拥有一个不断 –– 使用 SSE 指令 –– 读取或写入一个 2MB memory区块的行程。选择 2MB 是因为这是这个 Core 2 处理器的 L2 cache大小的一半。行程被钉在一颗处理器核上，而第二个行程则被钉在另一颗处理器核上。第二个行程读写一块可变大小的memory区域。图表显示每周期被读取或写入的位元组数。显示四条不同的曲线，每条代表一种行程读取与写入的组合。其中 read/write 曲线代表一个总是写入 2MB 工作集的背景行程，和一个读取可变工作集、用于测量的行程。

这张图有趣的部分在于 2²⁰ 与 2²³ 位元组之间。若是两颗处理器核的 L2 cache完全分离，我们能够预期四个测试的效能全都会在 2²¹ 与 2²² 之间 –– 这表示，L2 cache耗尽的时候 –– 往下掉。如同我们能在图 3.31 中看到的，情况并非如此。以在背景行程写入的情况而言，这是最明显的。效能在工作集大小达到 1MB 之前就开始下降。两个行程没有共享memory，因此行程也不会导致 RFO 讯息被产生。这纯粹是逐出的问题。智慧型cache管理有它的问题，导致感觉到的cache大小比起每颗处理器核可用的 2MB，更接近于 1MB。只能期望，若是在处理器核之间共享的cache依旧是未来处理器的特征的话，智慧型cache管理所使用的演算法会被修正。

有一个拥有两个 L2 cache的四核处理器仅是能够引入更高层级cache之前的权宜之计。比起独立的插槽与双核处理器，这个设计并没有什么显著的效能优势。两颗处理器核透过在外部被视为 FSB 的相同的总线沟通。没有什么特别快的资料交换。

针对多核处理器的cache设计的未来将会有更多的层级。AMD 的 10h 处理器家族起个头。我们是否会继续看到被一个处理器核的一个子集所共享的更低层级的cache仍有待观察（在 2008 年处理器的世代中，L2 cache没有被共享）。额外的cache层级是必要的，因为高速与频繁使用的cache无法被多颗处理器核所共享。效能会受到影响。也会需要非常大的高关联度cache。cache大小以及关联度两者都必须随著共享cache的处理器核数量而增长。使用一个大的 L3 cache以及合理大小的 L2 cache是个适当的权衡。L3 cache较慢，但它理想上并不如 L2 cache一样常被使用。

对程序开发者而言，所有这些不同的设计都代表进行排程决策时的复杂性。为了达到最好的效能，必须知道工作负载以及机器架构的细节。幸运的是，我们拥有确定机器架构的依据。这些介面会在之后的章节中介绍。