Cost-Effective Speculative Scheduling in High Performance Processors

Cost-Effective Speculative Scheduling in High Performance Processors

1. 摘要

   • 背景：
     • 为了最大化性能，乱序执行处理器中，有些情况下会在操作数尚未可用的情况下发射该指令，例如load指令通常会被推测认为在L1 cache中命中，并且之后的相关指令（消费者指令）也认为L1 cache会命中，这种情况下就被认为是推测调度
     • 随着流水线深度的增加和Issue和Exe阶段之间的距离增加（尽早的发射依赖于可变延迟指令的指令，而不是等待结果可用的实际周期再发射），此时会出现调度的指令到达执行阶段时，指令所需要的源寄存器仍旧不在旁路网络上。这种情况下，调度的指令必须取消和重新执行，从而可能会影响性能，并且增加能量消耗
   • 论文工作：主要研究如何减少和重执行（replay）方案无关的重执行的次数
     • 首先论文提出了一种简单，低开销的解决由于L1 bank冲突而引起的replay的次数的方案：Scheduling Shifting，对于给定可以同一周期发射两条load指令的结构，在给定的周期，由于bank冲突，第二条load指令必须延迟，并且该指令的消费者指令也要被延迟发射
     • 其次，论文通过考虑指令的关键性（criticality），改进了现有的L1 hit/miss预测机制。对于某些非关键性以及hit/miss行为难以预测的load指令，论文发现，此时停止发射相关的指令的成本效益更高
   • 结果：在发射到执行的延迟为4周期的实验环境中，论文发现由于L1 Dcache bank冲突而导致的绝对大多数重新执行的指令（78%）和L1 命中错误预测而导致的（96.5%）可以被避免，从而可以提高3.4%的性能，发射的指令数减少13.4%

2. 介绍：

   • 在乱序执行中，当指令发射后，需要等待若干周期：首先将指令标记为可执行，然后从寄存器文件中读取操作数，并且需要从bypass网络和PRF中选择一个有效的操作数，最后执行指令

   • 对于两条紧接相关的指令inst0和inst1，发射inst1的决定必须在有效执行inst0之前确定。如果发射阶段和执行阶段之间差距N个周期，并且inst0的延迟为P，则inst1必须P周期后发射，并且在N+P周期获得其源操作数
     

   • Speculative Scheduling（推测调度）：推测发射指令并且不确定在指令开始执行时源操作数是否可用

   • 问题：某些指令或者在某些情况下，指令的有效延迟并不能够完全确定，例如load指令。此时为了保证确定性，应该延迟所有load相关的指令，直到load指令发出了命中信号

   • 推测调度命中位置不确定的load指令：因为load指令在大部分情况下会在L1 D-cache中命中，因此在调度时，使用L1 命中的延迟进行推测调度，当发现L1未命中时，所有提前发射的相关指令都需要重新执行
     

   • load指令的访问冲突延迟：多端口的L1缓存的实现，主要通过物理上的多bank实现，如果两个load指令同时访问同一个bank，则后一个需要被延迟一个周期，这种情况下，意味着之后的相关指令也需要重新执行

   • 由于错误推测调度而造成的replay和recovery的损失：issue-to-exe的延迟为4，由于L1数据bank冲突会导致4.7%的性能下降（几何平均值）相对于理想的双端口Dcache

   • 论文工作：

     • Schedule Shifting（解决L1 Dcache的bank冲突）：对于同时发射两条load的周期，依赖于第二条load指令的指令，总是晚一个周期发射，因为如果发生bank冲突，第二个load指令将也会被延迟一个周期（减少了74.8%的由于L1 bank冲突而造成的replay，性能提升了2.8%）
     • 简单的L1 hit/miss过滤器（减少由于L1 miss而造成的replay次数）：减少了65%的由于此原因造成的replay指令，但是性能和基准几乎一样

3. 论文的实验环境

   • 模拟器：gem5(x86-64)，4GH，6发射的超标量流水线。fetch-to-commit延迟为19个周期，前端15个周期，后端四个周期，从而提供一个较为真实的分支错误预测代价：最小20个周期。具体参数：

   • 增加issue-to-exe的延迟：从0-6增加延迟。同时为了保持比较的公平性，保证分支错误预测的代价仍旧是20个周期，会不断减少前端时间，增加后端时间，例如baseline_0的前端为15周期，后端4周期；baseLine_6的前端变为9周期，后端增加到10周期

   • 基准程序：spec2000和spec2006的部分程序（由于论文使用的gem5版本中缺少一些系统调度和x87指令），以单线程方式运行。共18个定点，18个浮点，使用reference输入

4. 引起错误推测调度的原因

   • issue-to-exe延迟设置的原因：

     • 驱动寄存器读命令
     • 寄存器读访问时间
     • 驱动操作数传递到功能单元（包括bypass的多路选择器，RF读取等）

   • 由于issue-to-exe的延迟而造成的性能变化：（没有进行推测调度，即直到明确直到load发生了hit之后，才会调度之后的相关指令）
     

   • 由于一级cache未命中而造成的错误推测调度

     • load指令的延迟根据命中位置的不同而不同，如果调度器保守的等待hit的确定信号，正确性将可以得到保证，但是性能却会下降。如果调度器假设hit的位置，激进的调度相关指令，那么在发生load未命中时，相关指令必须能够取消和重新执行，因为使用了错误的数据执行
     • 在实际实现中，由于保守调度而产生的性能下降可能比由于L1未命中而重新执行而带来的性能损失更高。（在某些情况下，提前的无用指令发射会造成资源竞争或者重新执行某些不相关的指令都会造成性能下降，同时会浪费能量）

   • 由于L1缓存的bank冲突而造成的错误推测调度

     • 为了实现单周期多次L1缓存访问，并且尽可能减少能耗和复杂度，L1 dcache通常以bank的形式组织，而不是多端口，即如果访问不在同一个bank，则可以正常执行
     • 多bank的组织形式：set交叉和word交叉，前者允许交叉数据数组和tag数组，后者只交叉数据数组（例如为四字，双字和单字）而tag数组并且复制一份或者是双端口的。Sandy Bridge中L1 Dcache的组织是8-bank，四字交叉结构，因此也应用于论文
     • 如果两次load在同一个周期发生了冲突，则其中一条必须被延迟，即该条load指令的延迟会增加。在这种情况下，如果推测调度了被延迟load指令的相关指令，那么就会出现replay。更糟糕在于，如果多个相邻load都访问同一个bank，尽管这些load可能都会命中L1，但是所有的和这些load相关的指令都需要被重新执行

   • 由于PRF bank冲突而造成的错误推测调度

     • RF划分Bank适用于增加物理寄存器个数同时保存复杂性的一种技术，并且为了减少能量和延迟，每个单独的bank只提供更少的端口。因此在同一个发射组中的指令，如果需要访问同一个bank的RF，其中之一就需要被延迟，此时就是出现错误执行，即相关的指令必须replay

   • 由于PRF 写回冲突造成的错误推测调度

     • 由于微操作的执行延迟不相同，因此可能会出现在同一个周期有多个微操作指令完成执行，并且超过了写回端口的数目，此时某些微操作的写回操作将会被延迟。当下一次针对于其中某个寄存器的读发生时，如果之前的写回由于被延迟尚未写回，则会触发replay操作
     • 如果增加Writeback buffer用于缓存由于写回端口不够用而造成的写回延迟的指令，并且可以被之后的相关指令使用，则不再需要replay

5. Schedule Shifting（减少由于L1 cache bank冲突而造成的replay的数量）

   • 最简单的想法：假定所有的同一个周期发射的两条load指令都会产生L1的bank冲突，因此会将第二条load指令的所有相关者都延后发射一个周期，以保证数据可以正确拿回

   • 缺点：

     • 如果两个load之间没有冲突，则第二条load指令的load-to-use延迟会增加一个周期
     • 没有阻止bank冲突的发生，即延迟的第二条指令仍旧可能会和下一周期发射的load之间有相关
     • 如果两条load同时发射，并且都发生了miss，则会触发两次replay而不是一次，因为第二个load会增加一个额外的周期用于执行

   • 示例：
     

   • 结果：在issue-to-exe的延迟为4的情况下，性能平均提升了2.9%，由于L1 bank冲突导致的replay的指令数减少了74.8%
     

6. 使用hit/Miss过滤器减少由于hit/miss导致的replay的数量

   • 使用全局计数器：4位计数器，最高位用于决定是否唤醒load指令的相关指令。如果L1发生miss，计数器减2，否则加1。这种配置称为SpecSched_4_ctr
   • Per-instruction Filter：2K表项，直接映射，每个表项为2位饱和计数器，在L1 hit时增加，否则减少。并且每个表项增加额外的一位，用于判断是否静默该计数器。如果计数器从饱和状态转移到暂态(例如0->1)，则设置该额外的位，表项静默该计数器。
     • 静默的计数器不会再被更新
     • 为了防止永远静默某个计数器，因此每间隔10K条提交的load指令，重设整个silent位
     • 该方案称为SpecSched_4_Filter
   • 关键指令：在保证推测调度提供的大部分的性能提升的同时，减少replay的数量
     • 如果微指令正在ROB的头部，则将其标记为关键指令
     • 对于非关键指令，如果不能够被hit/miss判定为一定hit，则不唤醒任何相关指令；对于关键指令，不会被过滤掉
     • 这种结构称为SpecSched_4_Crit