SandyBridge核外架构的进化复习过程Word下载.docx

SandyBridge核外架构的进化复习过程Word下载.docx

《SandyBridge核外架构的进化复习过程Word下载.docx》由会员分享，可在线阅读，更多相关《SandyBridge核外架构的进化复习过程Word下载.docx（15页珍藏版）》请在冰豆网上搜索。

Bridge和Gesher都含有桥梁的意思。

而SandyBridge微架构将这个含义发挥到了极致，它是一个集NetBurst微架构与Nehalem微架构大成的产品，也是一个首先将CPU和GPU进行真正融合的产品，更是一个首先将浮点运算密度从128位引向256位的X86处理器产品，它确实像是一个桥梁，引导着芯片设计上和计算模式上的转变。

SandyBridge微架构为什么会是现在这个样子呢？

SandyBridge在上一代Nehalem微架构的基础上进行改进，如果不了解Nehalem微架构，就无法真正理解SandyBridge的进化。

Nehalem无疑是一个很成功的架构，QPI、IMC带来的直联架构，再加上超线程的回归，其性能比起上一代提升了一到两倍以上，在企业级市场、主流乃至高端桌面市场以及移动市场的压倒性的占有率充分地说明了Nehalem的强大。

当然，Nehalem微架构也不是完美的，以笔者的眼光看来，至少有几点Nehalem微架构是有待改进的：

指令拾取和预解码

Nehalem微架构在PentiumM微架构的基础上进行改进，整个流水线上几乎所有的组件都得到了增强，变化最少的就是在指令拾取和预解码阶段了。

这个阶段的作用是将要执行的指令从L1I-Cache中提取到CPU核心里面来，并随后对其进行预解码。

预解码的主要作用就是在一块代码块中辨认每条x86指令的长度。

和Penryn一样，Nehalem以及其改良版Westmere都仍然采用了16Bytes的指令拾取宽度，而竞争对手早已经采用了32Bytes的拾取宽度。

由于x86指令的长度可以从1到15Bytes，因此在很糟糕的情况下，某个时钟周期拾取到的代码块里只包含一个x86指令，和后端动辄6个、4个uop（微指令）的能力不相符合。

Nehalem微架构的指令拾取/预解码单元无法跟上后端处理的速度，因此在运行计算密集型的代码中，它很容易成为瓶颈。

寄存器读停顿

这个情形发生在uop经过RAT（RegisterAliasTable，寄存器别名表）进行寄存器重命名并发往ROB（ReOrderBuffer，重排序缓冲）之后，在这个被称为ROB-read的流水线阶段中，uop们需要读取相关的操作数，也就是读取对应的寄存器，如果这些内容在ROB当中不存在的话。

Nehalem微架构的RAT每时钟周期可以输出4个uop，每个uop可以具有最多两个输入寄存器。

这样它最多需要同时读取8个寄存器。

不幸的是，Nehalem微架构用于保存寄存器的RRF（RetirementRegisterFile，回退寄存器文件）仅具有3个读取端口，无法充分满足寄存器读取的需求，这很容易导致ROB-read以及前方流水线的停顿。

访存能力

Nehalem微架构具有6个执行端口，其中的3个运算端口具有充足的计算能力，基本不会是瓶颈。

然而，访存能力却不一定足够。

Nehalem微架构只有一个Load载入端口和一个Store保存端口。

由于Load操作是如此常见，可以达到uop总数的1/3，因此相对于3个运算端口，这个Load端口是个潜在的瓶颈，特别是对于内存密集型计算来说。

最后，早期的Nehalem架构上还存在大页面TLB数量较少的问题，TLB：

TranslationLookasideBuffer，旁路转换缓冲，或称为页表缓冲，里面存放的是虚拟地址到物理地址的转换表。

Nehalem具有较多的标准4KB页面TLB项，但是更大容量页面的TLB很少，因此，相对来说不适合大规模内存下的应用（如大型数据库和大型虚拟化环境，后来的Westmere通过增加了对1GB页面的支持缓解了这个问题）。

除了Nehalem微架构的一些问题之外，英特尔或者说CPU本身还面临着挑战，来自GPU的挑战。

目前，主要的GPU厂商包括NVIDIA和AMDATI都提供了超越CPU的强劲浮点处理能力，很多超级计算机通过采用了附加GPU的方式获得了很强的计算指标。

CPU能力的增强导致了如硬件解压卡、独立声卡被融合进CPU，而GPU强大的处理能力则被认为是CPU的有力挑战者。

如果运算能力足够强大，CPU被GPU取代也不无可能，英特尔怎么应对这个局面？

SandyBridge进行了什么样的改进、能不能解决这些问题呢？

原文发布于《计算机世界》2011年第4期

SandyBridge微架构的革新

——英特尔SandyBridge处理器分析测试之二

上文中笔者介绍了Nehalem微架构中存在的一些问题，到了SandyBridge这一代，这些问题还存在吗？

下面我们就来详细解析SandyBridge的微架构，并介绍相对于Nehalem微架构的改进。

前端：

分支预测和微指令缓存

分支预测、指令拾取、预解码以及解码这几个部件组成了处理器微架构的Front-End前端部分。

在Nehalem微架构中，指令拾取和预解码存在问题，在一些情况下会导致指令吞吐量过低，因此其前端是整个流水线当中最容易成为瓶颈的阶段。

SandyBridge没有直接在指令拾取和预解码阶段进行改动，而是对整个前端部分进行了重新设计，通过革新的分支预测单元以及在解码阶段加入一个新的部件来增强整个前端部分的输出能力，同样达到了消除瓶颈的目的。

处理器的前端从L1I-Cache拾取指令，在指令拾取单元没有什么变化的情况下，SandyBridge的L1I-Cache也有了些改进，提升了大型应用程序下的性能。

首先，它从Nehalem的4路组关联提升到了8路组关联，从而降低了CacheLine碰撞的几率，降低了页面冲突；

其次，L1I-Cache对应的L1ITLB也略微扩大，2M/4MB对应的TLB表项从Nehalem的7+7提升到了8+8（对每一个硬件线程提供8个表项），可以覆盖更大的代码地址空间。

分支预测是一个既能提升性能又能降低能耗的做法，成功的分支预测可以避免无谓分支代码执行的性能、功耗损失。

SandyBridge的分支预测单元在Nehalem的基础上进行了完全的重造。

通过对分支表结构的压缩定义，BTB（BranchTargetBuffer，分支目标缓存）在同样容量下将保存的分支目标翻番，同样，GBH（GlobalBranchHistory，全局分支历史表）也能保存更多、更深的项目，总的来说，分支预测准确率将会进一步提升。

前端变化中作用更明显的解码器旁边加入的uopcache（微指令缓存），这个部件和NetBurst微架构的TraceCache作用非常相似，不过却是经过了更多的调整和优化，并且更加简洁。

uopcache保存了已经解码的微指令，并且更加接近处理器的后端，因此也可以被称为L0I-Cache。

根据英特尔的说法，通常的应用当中其命中率可以达到80%，在命中这个缓存之后，包括复杂的解码器在内的其它前端部件可以关闭以节约能源，而由uopcache本身输出指令。

这个设计可以很明显地降指令拾取低延迟乃至分支惩罚，让前端可以在更多的时间内处于持续输出4uop/cycle的状态，这很大程度消除了Nehalem前端的瓶颈。

后端：

物理寄存器文件架构

Front-End前端紧接着的是Back-End后端部分，SandyBridge在后端部分也有了很大的变化，其中一个变化来自于寄存器文件的变迁。

在之前，我们介绍了Nehalem微架构采用的RRF（RetirementRegisterFile，回退寄存器文件）存在的会导致寄存器读停顿的问题，SandyBridge通过采用了PRF（PhysicalRegisterFile，物理寄存器文件）结构来消除了这个问题，和前面的uopcache一样，PRF的设计也是从NetBurst架构借鉴而来。

几乎所有的高性能处理器都采用了PRF的方式。

在Nehalem微架构当中，ROB（ReOrderBuffer，重排序缓存）顺序保存了所有uop及其所有的重命名寄存器的数据和状态，架构寄存器则保存在RRF当中。

在SandyBridge的PRF上，ROB不再保存重命名寄存器的数据，取而代之的是保存多个指向PRF的指针，架构寄存器包含在RRF当中，通过状态位来标识。

物理寄存器文件有什么好处？

首先，它消除了旧有的寄存器读停顿造成的瓶颈，现在它不再受限于RRF三个读取端口的限制，所有不同寄存器的内容都可以同时进行读取，不会再引起流水线停顿。

其次，物理寄存器文件消除了寄存器间数据的复制和移动，而只需要更改指针的指向即可，这节约了大量的数据移动能耗，特别是在SandyBridge的AVX指令集支持更多的操作数以及支持的最大寄存器宽度翻倍的情况下。

最后，ROB从保存数据变成保存指针导致了结构上的简化，从而增大了ROB的容量，进一步提升了处理器乱序执行的性能。

SandyBridge的ROB从Nehalem的128项提升到了168项，PRF物理寄存器文件包含了两个部分：

每项64bit、一共160项目的整数寄存器文件和每项256bit、一共144项目的浮点寄存器文件，并且PRF是每个硬件线程各自一份。

在SandyBridge架构当中，还增加了一个硬件监测机构，在使用SAVE/RESTORE指令进行线程切换或者虚拟机切换的时候，可以仅仅恢复/保存线程所使用到的寄存器，而不是恢复/保存所有的架构寄存器，从而节约了上下文切换的时间，这可以提升处理器运行大量线程和多个虚拟机的能力。

存取单元

微指令经过重命名阶段和读取PRF数据之后进入ReservationStation保留站，通过统一的调度器安排发射到6个不同的执行单元之中。

SandyBridge的ReservationStation容量从Nehalem的36项目提升到了54项目，增加了50%，乱序执行窗口的扩大可以提升处理器的乱序执行能力。

SandyBridge的执行单元也有了很大的改进。

执行单元包括计算单元以及存取单元，这两个都变化甚大，不过这里我们先介绍存取单元的变化，因为之前介绍过Nehalem微架构在这方面是个潜在的瓶颈。

计算单元的改进留到下一篇文章中再介绍。

SandyBridge架构和Nehalem一样具有3个存取端口，Store端口维持不变而Load端口的数量提升到了两个，并且这两个Load端口的AGU地址生成单元均能生成Store操作使用的地址。

Load端口翻番在某种程度上是为了适应SandyBridge处理器新增的AVX指令集带来的256位计算能力，因为每个Load端口的宽度是128位。

然而，现有的各种应用也可以立即从中获益，因为Nehalem微架构的Load端口仅占所有执行单口的1/6，而Load操作通常可以占据uop当中的约1/3。

SandyBridge的双Load端口可以每个时钟周期进行两个128位Load操作，消除了上一代的瓶颈，工作起来也更为灵活