Google Reader

上文中笔者介绍了Nehalem微架构中存在的一些问题， 到了Sandy Bridge 这一代，这些问题还存在吗？ 下面我们就来详细解析Sandy Bridge 的微架构，并介绍相对于Nehalem 微架构的改进。

分支预测、指令拾取、预解码以及解码这几个部件组成了处理器微架构的Front-End 前端部分。在Nehalem 微架构中，指令拾取和预解码存在问题，在一些情况下会导致指令吞吐量过低，因此其前端是整个流水线当中最容易成为瓶颈的阶段。Sandy Bridge没有直接在指令拾取和预解码阶段进行改动，而是对整个前端部分进行了重新设计，通过革新的分支预测单元以及在解码阶段加入一个新的部件来增强整个前端部分的输出能力，同样达到了消除瓶颈的目的。

处理器的前端从L1 I-Cache拾取指令，在指令拾取单元没有什么变化的情况下，Sandy Bridge 的L1 I-Cache 也有了些改进，提升了大型应用程序下的性能。首先，它从Nehalem 的4 路组关联提升到了8 路组关联，从而降低了CacheLine 碰撞的几率， 降低了页面冲突； 其次，L1 I-Cache 对应的L1 ITLB 也略微扩大，2M/4MB 对应的TLB 表项从Nehalem 的7+7 提升到了8+8（对每一个硬件线程提供8 个表项），可以覆盖更大的代码地址空间。

分支预测是一个既能提升性能又能降低能耗的做法，成功的分支预测可以避免无谓分支代码执行的性能、功耗损失。Sandy Bridge的分支预测单元在Nehalem的基础上进行了完全的重造。通过对分支表结构的压缩定义，BTB（Branch Target Buffer，分支目标缓存）在同样容量下将保存的分支目标翻番，同样，GBH（Global Branch History，全局分支历史表）也能保存更多、更深的项目，总的来说，分支预测准确率将会进一步提升。

前端变化中作用更明显的解码器旁边加入的uop cache（微指令缓存），这个部件和NetBurst 微架构的Trace Cache 作用非常相似，不过却是经过了更多的调整和优化， 并且更加简洁。uop cache 保存了已经解码的微指令，并且更加接近处理器的后端，因此也可以被称为L0 I-Cache。根据英特尔的说法，通常的应用当中其命中率可以达到80%， 在命中这个缓存之后，包括复杂的解码器在内的其它前端部件可以关闭以节约能源，而由uop cache 本身输出指令。这个设计可以很明显地降指令拾取低延迟乃至分支惩罚，让前端可以在更多的时间内处于持续输出4 uop/cycle 的状态，这很大程度消除了Nehalem 前端的瓶颈。

Front-End 前端紧接着的是Back-End 后端部分，Sandy Bridge在后端部分也有了很大的变化，其中一个变化来自于寄存器文件的变迁。在之前，我们介绍了Nehalem微架构采用的RRF（Retirement Register File，回退寄存器文件）存在的会导致寄存器读停顿的问题，Sandy Bridge 通过采用了PRF（Physical Register File，物理寄存器文件）结构来消除了这个问题，和前面的uop cache 一样，PRF 的设计也是从NetBurst 架构借鉴而来。几乎所有的高性能处理器都采用了PRF 的方式。

在Nehalem 微架构当中，ROB（ReOrder Buffer， 重排序缓存）顺序保存了所有uop 及其所有的重命名寄存器的数据和状态，架构寄存器则保存在RRF 当中。在SandyBridge 的PRF 上，ROB 不再保存重命名寄存器的数据，取而代之的是保存多个指向PRF 的指针，架构寄存器包含在RRF 当中，通过状态位来标识。

物理寄存器文件有什么好处？首先，它消除了旧有的寄存器读停顿造成的瓶颈，现在它不再受限于RRF 三个读取端口的限制，所有不同寄存器的内容都可以同时进行读取， 不会再引起流水线停顿。其次，物理寄存器文件消除了寄存器间数据的复制和移动，而只需要更改指针的指向即可，这节约了大量的数据移动能耗， 特别是在Sandy Bridge 的AVX 指令集支持更多的操作数以及支持的最大寄存器宽度翻倍的情况下。最后，ROB 从保存数据变成保存指针导致了结构上的简化， 从而增大了ROB 的容量，进一步提升了处理器乱序执行的性能。

Sandy Bridge 的ROB 从Nehalem 的128 项提升到了168项，PRF 物理寄存器文件包含了两个部分：每项64bit 、一共160项目的整数寄存器文件和每项256bit 、一共144 项目的浮点寄存器文件，并且PRF 是每个硬件线程各自一份。在Sandy Bridge架构当中，还增加了一个硬件监测机构，在使用SAVE/RESTORE指令进行线程切换或者虚拟机切换的时候，可以仅仅恢复/ 保存线程所使用到的寄存器，而不是恢复/ 保存所有的架构寄存器，从而节约了上下文切换的时间，这可以提升处理器运行大量线程和多个虚拟机的能力。

微指令经过重命名阶段和读取PRF 数据之后进入Reservation Station 保留站， 通过统一的调度器安排发射到6 个不同的执行单元之中。Sandy Bridge 的Reservation Station 容量从Nehalem 的36 项目提升到了54 项目，增加了50%，乱序执行窗口的扩大可以提升处理器的乱序执行能力。

Sandy Bridge 的执行单元也有了很大的改进。执行单元包括计算单元以及存取单元，这两个都变化甚大，不过这里我们先介绍存取单元的变化，因为之前介绍过Nehalem微架构在这方面是个潜在的瓶颈。计算单元的改进留到下一篇文章中再介绍。

Sandy Bridge 架构和Nehalem一样具有3 个存取端口，Store 端口维持不变而Load 端口的数量提升到了两个，并且这两个Load 端口的AGU 地址生成单元均能生成Store 操作使用的地址。Load 端口翻番在某种程度上是为了适应Sandy Bridge 处理器新增的AVX指令集带来的256 位计算能力，因为每个Load 端口的宽度是128 位。然而，现有的各种应用也可以立即从中获益， 因为Nehalem 微架构的Load 端口仅占所有执行单口的1/6， 而Load 操作通常可以占据uop 当中的约1/3。Sandy Bridge的双Load 端口可以每个时钟周期进行两个128 位Load 操作，消除了上一代的瓶颈，工作起来也更为灵活。

和Load/Store 单元连接的MOB（Memory Ordering Buffer， 内存排序缓存） 也得到了增强，MOB和前面的ROB 一起属于将乱序执行和顺序回退连接起来的重要部件。在MOB 当中，Load 缓存从Nehalem 的48 项目提升到了64 项目， 提升幅度为33%，Store 缓存从32 项目略微提升到了36 项目。

Sandy Bridge 的MOB 一共可以容纳100 个访存操作，这些数据操作均为256 位宽度。和Load 能力翻倍配对的是L1 D-Cache 的增强，它的带宽提升到了48 字节， 也就是384 位， 比以往的32 字节提升了50%，以同时支持两个128 位的Load 和一个128位的Store 操作。搭配的L1 DTLB据说也有所改进， 增加了4 个支持1GB 页面的项目，以进一部消除Nehalem 微架构在面对海量内存应用下的性能问题，这4 个大页面DTLB 项目应该是全关联的，其它的L1 DTLB 则应该维持4 路关联不变。

在L2 Cache 方面，Sandy Bridge 相对Nehalem 没有太大的变化。

可以看到， 通过将Nehalem微架构和NetBurst 微架构进行融合， 引入NetBurst 上的微指令缓存和物理寄存器文件架构，并改进Load/Store 单元和L1 D-Cache带宽设计，Sandy Bridge 消除了上一代Nehalem 微架构存在的比较明显的三个瓶颈，还顺带获得了更多的附加增益。Sandy Bridge在整个流水线的方方面面都得到了改进，然而还有一个很重要的部分没有被提及： 运算单元， 这个部分的变化和Sandy Bridge 引入的AVX 指令集紧密联系，请看下回继续分解。