这一节是我准备最后书写的内容，在此之前最后一章的书写早已完成。待到结束，总在回想动笔时的艰辛。这些艰辛使我选择一个Case Study作为结尾，因为这样做最为容易。这些Case实际存在的，不以你的喜好而改变。缺点与优点都在你面前，你无需改变，只需要简单的去按照事实去陈述。

Sandy Bridge是Nehalem微架构之后的Tock，并在Nehalem的基础上作出的较大的改动。本节重点关注Cache Hierarchy上的改动。鉴于篇幅，鉴于没有太多公开资料，我并不能在这里展现Sandy Bridge微架构的全貌，即便只限于Cache Hierarchy层面。这一遗憾给予我最大的帮助是可以迅速完成本节。

Intel并没有公开Sandy Bridge的细节，没有太多可供检索的参考资料。David Kanter在Realworldtech上发表的文章[69][99]较为详尽，但这并不是来自官方，鉴于没有太多公开资料，本篇仍然使用了David Kanter的文章。虽然我知道真正可作为检索的资料是Intel发布的Intel 64 and IA-32 Architectures OptimizationReference Manual中的第2.1.1节[98]和Intel在2010年IDF上公开的视频http://www.intel.com/idf/audio_sessions.htm[1]。

Sandy Bridge包含两层含义。首先是Sandy Bridge微架构，即Core部分，由指令流水，L1 Cache和L2 Cache组成，如图4‑16所示。其中指令流水的Scheduler部件，和Load，Store部件需要重点关注，最值得关注的是L1和L2 Cache的组成结构。

从CPUCore的角度上看，Sandy Bridge与Nehalem相比，并没有太多质的变化。最值得关注的是Sandy Bridge增加的L0 Instruction Cache和PRF(Physical Register File)。L0 Instruction Cache也被称为Decoded μops Cache，这是Sandy Bridge在指令流水中相对于Nehalem微架构的重大改进。PRF替换了Nehalem微架构使用的CRRF(Centralized Retirement RegisterFile)。PRF不是什么新技术，只是Intel实现的晚了些。

在Core和Nehalem微架构中，每一个μops包含Opcode和Operand。这些μops在经过指令流水执行时需要经过若干Buffer，有些Buffer虽然只需要Opcode，但是也必须要同时容纳Operand，因而带来了不必要的硬件开销。在Core微架构时代，Operand最大为80b，Nehalem为128b，到了Sandy Bridge微架构，Operand最大为256b。

如果SandyBridge不使用PRF，支持AVX(Advanced Vector Extension)的代价会变得无法承受，因为有些AVX指令的Operand过长。AVX的出现不仅影响了指令流水线的设计，也同时影响了Sandy Bridge的Memory子系统的设计。我们首先关注指令执行部件中的Memory Cluster，Memory Cluster即为LSU，其结构如图4‑17所示。

与Nehalem微架构在一个Cycle中只能执行一条128b的Load和Store指令[1][12]相比，Sandy Bridge微架构在一个Cycle中可以执行一条128b的Load和一条128b的Store指令，或者两条Load指令，进一步提高了Load指令的执行效率，在微架构设计中，通常会优先考虑Load指令，而不是Store指令。如果将Store指令提高为两条，其中因为Memory Consistency引发的同步并不容易处理。也因为这个原因，Sandy Bridge设置了两条Load通路，LSU与L1 Data Cache间的总线宽度也从Nehalem微架构的2×128b提高到3×128b。

合并Load和Store Address部件在情理之中，因为Load操作和Store Probe操作有相近之处，在现代处理器中，Store操作的第一步通常是Read for Ownership/Exclusive，首先需要读取数据后，再做进一步的处理。

在SandyBridge中，FLC和MLC的组成结构与Nehalem微架构类同。最大的改动显而易见，是在L1 Cache之上多加了一个读端口。单凭这一句话就够工程师忙碌很长时间。在Cache Memory层面任何一个小的改动，对于工程师都是一场噩梦。

其中FLC由指令Cache与数据Cache组成，由两个Thread共享；MLC为微架构内部的私有Cache。L1指令和数据Cache的大小均为32KB，MLC的大小为256KB。FLC和MLC的关系为NI/NE，组成结构为8-Way Set-Associative，Cache Block为64B，MPMB，Non-Blocking，Write-Allocate，Write Back和Write-Invalidate。Cache Coherence Protocol为MESI。

这些仅是SandyBridge微架构，即Core层面的内容。Sandy Bridge的另一层含义是Sandy Bridge处理器。Sandy Bridge处理器以Sandy Bridge微架构为基础，包括用于笔记本和台式机的Sandy Bridge处理器，和Server使用的Sandy Bridge EP处理器。但是Sandy Bridge和Sandy Bridge EP在Uncore部分的设计略有不同，本节重点讲述Sandy Bridge EP处理器。

Sandy Bridge EP处理器由CPU Core，iMC控制器(Home Agent)[98]，Cache Box[1][99]，PCIe Agent，QPI Agent和LLC(L3 Cache)组成，由Ring Bus(Ring-Based的Interconnect)连接在一起，并在其内部集成Graphics Controller，其组成结构如图4‑18所示。

其中CacheBox是Core与Uncore部分的连接纽带。如图4‑18所示，Cache Box提供了三个接口，与CPU Core，LLC和Ring Bus的接口。Cache Box的主要功能是维护Sandy Bridge EP处理器中CPU Core与Core间的Memory Consistency，并将来自CPU Core的数据请求发送到合适的LLC Slice或者其他设备中[1]。

Sandy BridgeEP处理器的LLC采用Distributed方式，每一个CPU Core都有一个对应的LLC Slice，每个Slice的大小可以是0.5/1/1.5/2MB，可以使用4/8/12/16-Way Associated方式。这不意味着每一个CPU Core都有一个私有Slice。

来自CPUCore的数据访问在经过Cache Box时，首先进行Hush，并通过Ring Bus转发到合适的Cache Slice。但是从逻辑层面上看这些Slice组成一个LLC。Sandy Bridge EP处理器的LLC与Core内Cache的关系是Inclusive，与Nehalem的L3 Cache类同。这意味着空间的浪费，也意味着天然的Snoop Filter[99]。

所有CPUCore，LLC Slice，QPI Agent，iMC，PCIe Agent，GT(Graphics uniT)通过Ring Bus连接在一起[1][99]。Ring Bus是Sandy Bridge EP处理器的设计核心，也意味着GT可以方便的与CPU Core进行Cache Coherence操作。这在一定程度上决定了Sandy Bridge处理器横空出世后，基于PCIe总线的Nvidia Graphics Unit黯然离场。

Sandy BridgeEP处理器的Ring Bus，采用Fully Pipelined方式实现，其工作频率与CPU Core相同，并由四个Sub-Ring Bus组成，分别是Data Ring，Request Ring，Acknowledge Ring和Snoop Ring[1]，其中Data Ring的数据宽度为256位。这些Sub-Ring Bus协调工作，共同完成Ring Bus上的各类总线Transaction，如Request，Data，Snoop和Response。采用4个Sub-Ring Bus可以在最大程度上使不同种类的Transaction并发执行。

Sandy BridgeEP处理器的这些Sub-Ring Bus谈不上是什么创新，所有使用了Ring Bus结构的现代处理器都需要这么做。由于Dual Ring的存在，Sub-Ring中通常含有两条总线，可能只有Snoop Ring除外，所以在Sandy Bridge的Ring Bus至少由7条Bus组成[1]。

在RingBus上，还有两个重要的Agent，一个是Memory Agent，另一个是QPI Agent。其中Memory Agent用来管理主存储器，包括iMC，而QPI Agent用于管理QPI链路，并进行与其他Sandy Bridge EP处理器互联，组成较为复杂的ccNUMA处理器系统。

以上是对Sandy BridgeEP处理器与Memory Hierarchy结构的简单介绍，下文将以此为基础进一步说明Sandy Bridge EP处理器如何进行Load操作。

剩余的内容需要等待Intel公开Sandy Bridge EP使用的Transaction Flow，估计会在Sandy Bridge EP正式发布时公开。Sandy Bridge EP的正式发布推迟到了2012年Q1，那时我会重新书写本节。整篇文章需要更改的地方还有很多。