英特尔SandyBridge处理器分析测试.doc

英特尔Sandy Bridge处理器分析测试Nehalem 的遗憾——英特尔Sandy Bridge 处理器分析测试之一计算机世界实验室 盘骏英特尔的“Tick-Tock” 战略已经为人熟知，根据这个策略，英特尔每年都会交替在处理器的制程和微架构上进行更新上一年，英特尔将处理器工艺从45nm 提升到了32nm，今年，英特尔将处理器架构从Nehalem 升级到最新一代的Sandy Bridge，这个早期被叫做Gesher（希伯来文：桥梁）的处理器微架构担任着特别的桥梁角色Bridge 和Gesher 都含有桥梁的意思而Sandy Bridge 微架构将这个含义发挥到了极致，它是一个集NetBurst 微架构与Nehalem 微架构大成的产品，也是一个首先将CPU和GPU 进行真正融合的产品，更是一个首先将浮点运算密度从128 位引向256 位的X86 处理器产品，它确实像是一个桥梁，引导着芯片设计上和计算模式上的转变Sandy Bridge 微架构为什么会是现在这个样子呢？ Sandy Bridge 在上一代Nehalem 微架构的基础上进行改进，如果不了解Nehalem 微架构，就无法真正理解Sandy Bridge的进化。

Nehalem 无疑是一个很成功的架构，QPI、IMC 带来的直联架构，再加上超线程的回归，其性能比起上一代提升了一到两倍以上，在企业级市场、主流乃至高端桌面市场以及移动市场的压倒性的占有率充分地说明了Nehalem 的强大当然，Nehalem 微架构也不是完美的，以笔者的眼光看来，至少有几点Nehalem 微架构是有待改进的：指令拾取和预解码Nehalem 微架构在Pentium M微架构的基础上进行改进，整个流水线上几乎所有的组件都得到了增强，变化最少的就是在指令拾取和预解码阶段了这个阶段的作用是将要执行的指令从L1 I-Cache 中提取到CPU 核心里面来，并随后对其进行预解码预解码的主要作用就是在一块代码块中辨认每条x86 指令的长度和Penryn 一样，Nehalem 以及其改良版Westmere 都仍然采用了16Bytes 的指令拾取宽度，而竞争对手早已经采用了32Bytes 的拾取宽度由于x86 指令的长度可以从1到15Bytes，因此在很糟糕的情况下，某个时钟周期拾取到的代码块里只包含一个x86 指令，和后端动辄6个、4 个uop（微指令）的能力不相符合Nehalem 微架构的指令拾取/预解码单元无法跟上后端处理的速度，因此在运行计算密集型的代码中，它很容易成为瓶颈。

寄存器读停顿这个情形发生在uop 经过RAT（Register Alias Table，寄存器别名表）进行寄存器重命名并发往ROB（ReOrder Buffer，重排序缓冲）之后，在这个被称为ROB-read 的流水线阶段中，uop 们需要读取相关的操作数，也就是读取对应的寄存器，如果这些内容在ROB 当中不存在的话Nehalem 微架构的RAT 每时钟周期可以输出4 个uop，每个uop可以具有最多两个输入寄存器这样它最多需要同时读取8 个寄存器不幸的是，Nehalem 微架构用于保存寄存器的RRF（Retirement Register File，回退寄存器文件）仅具有3 个读取端口，无法充分满足寄存器读取的需求，这很容易导致ROB-read 以及前方流水线的停顿访存能力Nehalem 微架构具有6 个执行端口，其中的3 个运算端口具有充足的计算能力，基本不会是瓶颈然而，访存能力却不一定足够Nehalem 微架构只有一个Load 载入端口和一个Store 保存端口由于Load 操作是如此常见，可以达到uop 总数的1/3，因此相对于3 个运算端口，这个Load 端口是个潜在的瓶颈，特别是对于内存密集型计算来说。

最后， 早期的Nehalem 架构上还存在大页面TLB 数量较少的问题，TLB：Translation Lookaside Buffer，旁路转换缓冲，或称为页表缓冲，里面存放的是虚拟地址到物理地址的转换表Nehalem 具有较多的标准4KB 页面TLB 项，但是更大容量页面的TLB 很少，因此，相对来说不适合大规模内存下的应用（如大型数据库和大型虚拟化环境，后来的Westmere 通过增加了对1GB 页面的支持缓解了这个问题）除了Nehalem 微架构的一些问题之外，英特尔或者说CPU 本身还面临着挑战，来自GPU 的挑战目前，主要的GPU 厂商包括NVIDIA和AMD ATI 都提供了超越CPU 的强劲浮点处理能力，很多超级计算机通过采用了附加GPU 的方式获得了很强的计算指标CPU 能力的增强导致了如硬件解压卡、独立声卡被融合进CPU，而GPU 强大的处理能力则被认为是CPU 的有力挑战者如果运算能力足够强大，CPU 被GPU 取代也不无可能，英特尔怎么应对这个局面？ Sandy Bridge 进行了什么样的改进、能不能解决这些问题呢？Sandy Bridge微架构的革新——英特尔Sandy Bridge 处理器分析测试之二计算机世界实验室 盘骏上文中笔者介绍了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/3Sandy Bridge的双Load 端口可以每个时钟周期进行两个128 位Load 操作，消除了上一代的瓶颈，工作起来也更为灵活和Load/Store 单元连接的MOB（Memory Ordering Buffe。