Sandy Bridge微架构的革新

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

　　前端：

　　分支预测和微指令缓存

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

　　处理器的前端从L1 I-Cache拾取指令，在指令拾取单元没有什么变化的情况下，Sandy Bridge的L1 I-Cache也有了些改进，提升了大型应用程序下的性能。首先，它从Nehalem的4路组关联提升到了8路组关联，从而降低了Cache Line碰撞的几率，降低了页面冲突；其次，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当中。在Sandy Bridge的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指令集紧密联系，请看下回继续分解。