Sandy Bridge微架构的革新——英特尔Sandy Bridge 处理器分析测试之二

作者 | 2011-01-27 07:07 | 类型 专题分析, 芯片技术 | 23条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




系列目录 英特尔Sandy Bridge处理器分析测试

  1. Nehalem的遗憾——英特尔Sandy Bridge处理器分析测试之一
  2. Sandy Bridge微架构的革新——英特尔Sandy Bridge 处理器分析测试之二
  3. AVX高级矢量扩展指令集——英特尔Sandy Bridge 处理器分析测试之三
  4. Sandy Bridge核外架构的进化——英特尔Sandy Bridge 处理器分析测试之四

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

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/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 指令集紧密联系，请看下回继续分解。
系列前一篇 系列下一篇
(4个打分， 平均：5.00 / 5)

工具箱
本文链接 | | 打印此页 | 23条用户评论 »

雁过留声

“Sandy Bridge微架构的革新——英特尔Sandy Bridge 处理器分析测试之二”有23个回复

  1. Lucifer 于 2011-01-27 7:22 上午

    次回和次次回和次次次回休息……
    架构图不够清晰，次次次次回或会补上

  2. Kevin 于 2011-01-27 9:54 上午

    还是在玩命的提高ILP

  3. coder 于 2011-01-27 4:29 下午

    可不可以详细分析一下GPU和CPU之间的 coherent communication.

  4. bigrong 于 2011-01-27 5:21 下午

    测试数据在哪里呢？

  5. 吴朱华 于 2011-01-27 6:04 下午

    呵呵，好东西，先存着。

  6. 老韩 于 2011-01-27 6:13 下午

    先分析完异同，才有针对性的测试。

  7. 张弛 于 2011-01-27 8:35 下午

    CNW再转走

  8. Lucifer 于 2011-01-27 9:21 下午

    @Kevin 持续提升单核心性能还是不错的吧，TLP方面有超线程和多核
    @coder 这个未来会稍微谈到，不过资料不是很多，还要多确认；比较确定的是gpu的行为是通过驱动来控制的，而cpu和l3之间是硬件管理的
    @bigrong 测试数据网上有很多，可以很容易找到；当然可能我们的测试会有些不同。需要点时间

  9. caijimin 于 2011-01-31 6:35 下午

    SandyBridge芯片组发现重大bug，SATA控制器越用越慢直到挂，3亿美金召回
    瘾科技报道
    http://www.engadget.com/2011/01/31/intel-finds-sandy-bridge-chipset-design-flaw-shipments-stopped/

    Intel官方新闻

    http://newsroom.intel.com/community/intel_newsroom/blog/2011/01/31/intel-identifies-chipset-design-error-implementing-solution?cid=rss-258152-c1-264102

  10. spike 于 2011-02-01 4:33 上午

    “而在本次“缺陷门”事件中，存在问题的并非是Sandy Bridge处理器，而是6系列芯片组（代号Cougar Point）中集成的SATA设备控制器（连接SATA接口的硬盘、光驱等设备）。”

  11. 老韩 于 2011-02-01 10:49 下午

    放假前还看见PCWorld China的哥们累死累活加班在做6系芯片组主板的横向评测，要在节后第一期上，这下糟了……

  12. Lucifer 于 2011-02-02 12:01 上午

    这bug对短期的功能性和性能没啥影响，评测还是可以做的，就怕召回之后再回来板子又不一样了

  13. Ma Ling 于 2011-07-14 5:52 上午

    “同样，GBH（Global Branch History，全局分支历史表）也能保存更多、更深的项目”
    这个评论有问题，
    用GBH的比local predicator 好处是：

    1. 较少的硬件 相同的预测结果
    2. 较少的训练得到快速准确的预测尤其对于中断，系统调用。
    3 替代Nehalem中的 loop counter.

  14. Ma Ling 于 2011-07-14 6:00 上午

    “是L1 D-Cache 的增强，它的带宽提升到了48 字节， ”
    still is 32bytes and Critical Word First.

  15. Lucifer 于 2011-07-14 8:30 上午

    ……原文写的是GBH和原GBH的变化，不知道你是从哪个虚空中看到了local predicator

    至于2……白纸黑字的，不予置评

  16. Ma Ling 于 2011-07-14 9:31 上午

    lucifer ，请照对：The microarchitecture of Intel, AMD and
    VIA CPUs
    An optimization guide for assembly programmers and
    compiler makers
    其中的 第26页，nehalem使用的是loop counter,sandy bridge 变成了 gbh，gbh 的优点我已经说过了。
    对于你不予置评的我来说清楚
    snb 一个cycle 要么 是 2个读 要么是一个读一个写，总是 32bytes, 不会 2个读一个写同时发生。
    你也可以参照 intel最新的
    Intel® 64 and IA-32
    Architectures
    Optimization Reference Manual
    里面说的很清楚。

  17. Ma Ling 于 2011-07-14 9:37 上午

    local predicator 是最重要的，每个有良好预测机制的cpu 都一定要实现他请参照
    ：

    <>
    这里的predicator 就是我们通常所描述的 local predicator.

  18. Ma Ling 于 2011-07-14 9:38 上午

    漏掉了
    请参照
    <>

  19. Ma Ling 于 2011-07-14 9:38 上午

    Alternative-implementations-of-two-level-adaptive-branch-prediction

  20. Lucifer 于 2011-07-20 4:14 上午

    global branch history一直都存在的好不好，跟loop counter不是同一个概念

    白纸黑字的，还是不予置评，自己去看看吧

    你的逻辑很混乱，无法交流

  21. Ma Ling 于 2011-07-20 5:21 上午

    又是一个不予置评，

    你上次不予置评的事情（如下）我说错了么？
    Lucifer : “是L1 D-Cache 的增强，它的带宽提升到了48 字节”

    Ma Ling : snb 一个cycle 要么 是 2个读 要么是一个读一个写，总是 32bytes, 不会 2个读一个写同时发生。”

    现在我们谈 GBH 还有 loop counter 是不是一个概念。
    下面为 agner 的www.agner.org/optimize/microarchitecture

    3.7 Branch prediction in Intel Sandy Bridge

    …There is no specialized loop predictor. Nested loops and
    loops with branches inside are not predicted particularly well …

    他说loop counter 是 用来对付 嵌套循环 和循环中有跳转的cases.

    所以我们再看下面关paper 中的这方面的内容：
    Combining branch predictors – McFarling
    它被引用1029次可以奉为经典。

    在 5 Global Branch Prediction 中专门讲了 GBP 对嵌套循环的好处

    所以GBH 与 loop counter 是一回事情，但是我同意 local predicator 与 global predicator 一直存在。

    闻道有先后，术业有专攻，如是而已，呵呵。

  22. Lucifer 于 2011-07-20 9:12 下午

    逻辑混乱，gbh一直都存在，原文说的是gbh的改进，你跳出来扯其他啥……

    snb可以同时两个读和一个写

    就这样，扯其他的无意义，只是显而已

  23. Ma Ling 于 2011-07-20 9:56 下午

    Lucifer: “逻辑混乱，gbh一直都存在，原文说的是gbh的改进，你跳出来扯其他啥……”
    Ma Ling: “是你说 gbh 与 loop counter 不是一个概念，而事实 证明他们都是用来处理 循环嵌套，你错了， 应该承认。而且我已经说过 同意gbh 与 local predicator 一直存在”

    Lucifer：“ snb可以同时两个读和一个写”

    Ma Ling: ” 链接 http://www.intel.com/Assets/PDF/manual/248966.pdf?wapkw=(Optimization+Reference+Manual)
    中的 2.1.5.1 Load and Store Operation 节已经很清楚的告诉你 SNB的L1 data cache 的 Bandwidth (per core per cycle) 是 32, 难道你比我们最新的手册还准确？”

    Lucifer： “就这样，扯其他的无意义，只是显而已”
    Ma Ling: “用事实说话，是工程师的基本职业准则，
    我不能信口开河，同时要说明根本原因。这里我来说说为什么只能有一个写，一个读或者两个读：因为过去 pipe2 是用来load内存， pipe3 用来 sotore address 同时 pipe4 用来 store data ，因为一个写操作需要两个 unfused uops(store address 和 store data)所以 需要 pipe3 和 pipe4 协同工作来处理一个内存写操作，所以过去只能有 一个读一个写。 在 SNB中 pipe3经过优化使 pipe3增添读的功能同时pipe2也有 store address的功能，所以 可以一个 cycle发出 2个读或者一个读一个写，但是 如果发出两个读操作，对于写的操作就没有可用的pipe(pipe2 或者 pipe3)来 做store address的操作，所以写不能从 reserve station中发射直到两个读中的一个提交数据。我说的每一个细节都有资料可查，Jucifer 我认为你需要坐下来安安静静的多看写书，而不是如此浮躁，如有得罪请见谅。”