体系结构论文（五十四）：Reliability-Aware Runahead 【22‘ HPCA】

一、文章介绍

问题背景

随着半导体技术的进步，处理器的核心微架构（比如重新排序缓冲区、指令队列、寄存器文件等）变得越来越复杂，这些结构的规模越来越大，这也意味着在处理器等待内存返回数据的过程中，更多的状态信息会长期暴露，导致更高的软错误风险。

这些错误是由于辐射或能量粒子撞击引起的，可能导致位翻转，进而破坏处理器的架构状态，降低系统的可靠性。通常，内存密集型工作负载会导致处理器长时间等待数据返回，在此期间，处理器后端的资源（如重新排序缓冲区（ROB）、指令队列（IQ）、加载队列（LQ）和存储队列（SQ））会被填满并暴露在软错误的风险下。

随着微架构状态的增大，传统的解决方法（如错误检测与纠正，ECC，或冗余执行）效果有限，因为它们带来了较大的性能和能耗开销。而另一种方法，如流水线清空或调度限制，虽然可以提高可靠性，但却严重影响性能，因为它们减少了处理器能够利用的内存级并行性。

运行前执行技术的关键发现

本文的一个关键发现是，运行前执行（Runahead Execution），一种本来旨在提高性能的技术，意外地也能提升软错误的可靠性。在长延迟的内存访问期间，运行前执行通过推测执行未来的指令流，来寻找更多的内存级并行性。这种推测的状态本质上是不易受软错误影响的。

然而，当前最先进的运行前执行技术——精准运行前执行（Precise Runahead Execution, PRE），虽然在性能方面表现出色，但在可靠性方面仍然存在两大不足：

启动运行前执行的时机过晚。
在运行前执行期间，处理器后端仍保持易受软错误影响的状态。

可靠性感知运行前执行（RAR）的改进

为了改进现有的 PRE 技术，本文提出了可靠性感知运行前执行（RAR），并进行两项关键优化：

后端状态清空：在运行前执行结束时，RAR 会清空处理器的后端状态，使其在执行期间不暴露易受软错误影响的状态。
提前启动：RAR 在内存访问阻塞 ROB 提交时立即启动运行前执行，而不是等到 ROB 完全填满。

这两项优化协同工作，既提升了系统的可靠性（通过减少暴露在软错误下的状态），也保持了较高的性能。

评价结果

通过对一组内存密集型应用程序的测试，RAR 在平均故障间隔时间（MTTF）上提升了 4.8 倍，并且平均性能提高了 33.5%。在更广泛的计算和内存密集型基准测试中，RAR 的 MTTF 提升了 2.5 倍，性能提升了 11.9%。

贡献

证明了长延迟内存访问会暴露处理器后端的易受攻击状态，尤其是随着后端结构规模的增加，可靠性问题更加严重。
分析了运行前执行技术如何意外地提高软错误可靠性，并指出了现有 PRE 技术的不足。
提出了 RAR 技术，通过清空后端状态和提前启动运行前执行来显著提升可靠性和性能。
通过测试展示了 RAR 在可靠性和性能上的显著改进，使其成为最有效的设计方案。

二、文章动机

A. 乱序处理器中的易受攻击的微架构状态

乱序处理器会暴露大量的微架构状态，这些状态在指令执行过程中占用后端资源，并且容易受到软错误的影响。

该图展示了乱序执行（OoO）核心中后端资源的分配和释放过程。

从指令的重命名（rename）和调度（dispatch）开始，后端资源如指令队列（Issue Queue）、功能单元（Functional Unit）、寄存器文件（Register File）以及重新排序缓冲区（Reorder Buffer）等，依次被指令占用并在指令提交（commit）后释放。

不同的资源在指令的不同阶段（如调度、执行和提交）期间被占用。例如，重新排序缓冲区（ROB）从调度开始到提交阶段一直被占用，而功能单元（FU）仅在执行阶段被占用。

乱序处理器的执行流程：

乱序处理器从流水线的前端取指、解码并重命名指令，然后将其调度到后端的资源中。
调度会在重新排序缓冲区（ROB）和指令队列（IQ）中分配条目，加载指令会进入加载队列（LQ），存储指令会进入存储队列（SQ）。
当指令的操作数准备好后，指令会被发射到功能单元（FU）执行。执行后，结果存储在物理寄存器文件（RF）中，依赖的指令被唤醒，ROB 更新指令状态为可提交。
当所有在程序顺序中排在前面的指令都提交后，指令会被提交（commit），并释放其占用的所有后端资源。

该图展示了不同基准测试中建筑相关暴露位（ACE bits）的堆栈，按不同的后端资源分类（例如，ROB、IQ、LQ 等）。

图中不同颜色表示不同资源暴露的位数，堆叠展示了每种资源在不同基准测试中的暴露程度。

图中可以看出，重排序缓冲区（ROB）、指令队列（IQ）、加载队列（LQ）和寄存器文件（RF）是暴露位最多的资源，特别是在内存密集型工作负载（例如 “mcf”）中，这些资源暴露了大量的易受软错误影响的状态。

暴露的易受攻击状态：

正确路径上的指令从资源分配到释放的整个过程中都暴露易受软错误影响的状态。
ROB 条目在从调度到提交的这段时间是易受攻击的。
加载/存储队列的地址和数据值从执行到提交期间也是易受攻击的。
指令队列条目从调度到发射期间处于暴露状态。
物理寄存器从执行到提交之间易受攻击，尤其是在提交时转换为架构寄存器。
功能单元暴露的易受攻击位数取决于指令执行的周期数和位宽。

B. 软错误易感性的历史趋势

随着处理器的发展，乱序处理器的后端资源（例如 ROB、IQ 等）的规模不断增加，这导致软错误的易感性越来越严重。

表格列出了四种不同乱序核心的配置（Core-1 到 Core-4），每种核心配置有不同数量的资源分配，例如 ROB、指令队列、加载队列、存储队列、整数寄存器和浮点寄存器。

随着核心编号的增加，分配给各资源的条目数也增加，说明更大的核心配置有更多的硬件资源。

ROB 规模的扩展：

例如，Intel 处理器的 ROB 规模从 2008 年 Nehalem 的 128 条目增加到 2019 年 Ice Lake 的 352 条目，甚至苹果的 M1 处理器拥有 600 条目。

随着处理器资源的增大，暴露在软错误下的状态也随之增加，因为当 ROB 头被长延迟内存访问阻塞时，后端结构会积累更多的状态，增加软错误风险。

四个核心配置下的标准化 ABC 值（软错误的暴露位数量），分别用于一组基准测试。

随着核心的规模增加（Core-1 到 Core-4），后端结构的大小增加，暴露在软错误下的状态显著增加。

Core-4 是拥有最大后端结构的核心，软错误的暴露位数最高，表明随着处理器规模的增大，软错误的易受攻击性也显著增加。

软错误易感性的线性增长：

软错误的暴露状态随着后端结构的大小线性增长。以 352 条目 ROB 的 Core-4 为例，与 128 条目的 Core-1 相比，软错误易感性增加了 1.83 倍。

C. 暴露状态

为了更深入地理解乱序处理器中软错误的暴露状态，作者通过一系列实验分析了 ROB 填满（ROB 中的所有条目都已经被分配给尚未提交的指令）和 ROB 头阻塞（ROB 的头部（head）有指令无法提交，通常是因为某个长延迟的内存访问（比如缓存未命中）阻止了指令的提交）的情况下暴露的位数。

该图展示了内存访问如何影响乱序核心中不同情况（OoO 核心、ROB 阻塞和 ROB 填满）的 ABC 位数。

可以看到，当 ROB 被阻塞时，软错误的暴露位数会显著增加，尤其是在长延迟的内存访问期间。

对于一些基准测试（如 “mcf” 和 “libquantum”），在 ROB 头阻塞的情况下，暴露位数超过了 74%，表明长延迟内存访问对系统可靠性的影响非常显著。

ROB 填满的影响：

当一个加载指令在最后一级缓存（LLC）未命中时，ROB 头被阻塞，新的指令会被调度到 ROB 中，直到 ROB 填满。这时处理器后端资源被指令填满，暴露了大量的软错误易受攻击状态。

实验显示，ROB 填满导致的大量暴露位数会显著增加软错误风险。例如，“fotonik”和“libquantum”基准测试中，超过 74% 的 ACE 位是在 ROB 填满时暴露的。

ROB 头阻塞的影响：

ROB 头被长延迟内存访问阻塞时，即使不导致 ROB 完全填满，也会暴露大量的软错误状态。例如，一些基准测试中，虽然 ROB 并未填满，但大约 70.4% 到 87.7% 的软错误是由 ROB 头阻塞引起的。

三、前置知识与文章方法

A. 已有解决方案

Flushing（流水线清空）：

Flushing 是一种通过限制调度来减少处理器后端暴露的易受软错误影响状态的技术。更激进的版本是在阻塞的内存访问后清空指令流中的指令，这可以有效减少暴露的状态，并提升软错误可靠性。

当处理器遇到一个 长延迟的内存访问（如缓存未命中，需要从主存中读取数据）时，Flushing 会清空处理器流水线中所有等待执行或提交的指令，并等待该内存访问完成。

这个过程会将指令执行状态从处理器后端（例如 ROB、指令队列等结构）中清除，使这些状态在内存访问期间不再暴露在软错误的风险下。

优点：Flushing 可以有效地减少处理器暴露在软错误下的状态。先前在顺序处理器中应用 Flushing 的研究表明，它对提升软错误可靠性非常有效。

缺点：尽管 Flushing 在顺序处理器中性能影响较小，但在乱序处理器中会严重影响性能，因为它抑制了处理器在 ROB 中同时服务多个独立内存访问的内存级并行性（MLP）。

在 乱序处理器 中，处理器可以同时发起多个独立的内存请求（例如多个加载/存储指令），这使得处理器能够并行处理多个内存访问，从而隐藏单个长延迟内存访问的影响。

当处理器执行 Flushing 时，它会清空所有后续指令，导致处理器停止发起任何新的内存访问请求。

实验表明，随着 ROB 规模增大，Flushing 的性能损失加剧。在较小的 128 条目 ROB 处理器中，性能平均下降 7.6%，最大下降 15.8%；而在 352 条目 ROB 中，性能平均下降 12.2%，最大下降 36.5%。

结论：虽然 Flushing 是一种有效的提升软错误可靠性的技术，但其较高的性能开销使得它不是一个理想的设计选择。

Runahead（运行前执行）：

Runahead 是一种著名的微架构技术，最初是为在长延迟内存访问期间提高性能而设计的。本文首次指出 Runahead 还可以意外地降低软错误的易感性。

工作原理：当 ROB 被长延迟的内存访问阻塞时，处理器进入 Runahead 模式，继续调度指令，并推测性地执行未来的指令流。这一过程中，处理器生成未来内存访问的预取请求，并同时与阻塞的内存访问一同处理，从而利用 MLP 提升性能。

操作过程：

当 ROB 被长延迟内存访问填满时，处理器检查点保存当前架构状态，开始推测执行未来的指令流。
当内存访问返回后，处理器恢复原来的架构状态，并重新执行从阻塞内存访问处开始的指令。
由于 Runahead 模式期间已预取了未来的内存数据，后续指令通常会命中缓存，从而提高整体性能。

Precise Runahead Execution (PRE)：这是当前最先进的运行前执行技术，通过两项关键创新显著提高了性能：

PRE 观察到在进入 Runahead 模式时，通常有足够的指令队列和寄存器文件条目。PRE 利用这些空闲资源进行推测执行，而不需要重新填充处理器后端，从而减少了模式切换的开销。
PRE 并不执行所有的未来指令流，而是仅执行那些与未来内存访问相关的指令链。

PRE 观察到，在进入Runahead时，处理器的后端资源（指令队列和寄存器文件）通常还有足够的空闲条目。换句话说，尽管 ROB 可能已经被大量未完成的指令占据，无法继续发射新的指令，但指令队列和寄存器文件可能仍有一些空闲资源没有被完全占用。

PRE 利用观察到的这一情况进行了优化：

不用重新填充后端资源：由于指令队列和寄存器文件中有足够的空闲资源，PRE 不需要重新填充这些后端资源。它直接利用这些空闲条目来进行推测执行。这意味着处理器可以继续发射后续指令到执行流水线，而不需要清空或重新填充这些资源。
减少模式切换的开销：进入运行前执行模式时，通常需要一些开销来准备好执行环境（例如，确保流水线中有足够的资源来执行后续指令）。但是由于 PRE 可以直接利用现有的资源，因此减少了在进入和退出运行前执行模式时的模式切换开销。

PRE 的优缺点

性能提升：PRE 相比传统的 Runahead 提供了显著的性能提升，因其仅推测执行与内存访问相关的指令，减少了无效的执行负担。
可靠性不足：尽管 PRE 显著提高了性能，但在软错误可靠性方面的改进有限。原因在于 PRE 在运行前执行期间仍然保持了后端的微架构状态，这些状态容易受到软错误的影响，因此它的可靠性提升不如 Flushing 技术。

B. 克服现有技术的缺点

上一部分提到的 Flushing 和 PRE 技术各有利弊：

Flushing 提高了软错误的可靠性，但以牺牲性能为代价。
PRE提高了性能，但对软错误的可靠性提升有限。 RAR 的目标是同时显著提升软错误的可靠性和处理器性能，尤其是解决 PRE 的两个主要问题：

运行前执行的启动过晚：PRE 要等到 ROB 完全填满才启动运行前执行，这会错失在 ROB 没有完全填满但已经积累了大量易受攻击状态的情况。
暴露状态问题：PRE 在运行前执行期间仍然保留 ROB 中的指令，导致微架构状态易受软错误影响。

C. 可靠性感知运行前执行（RAR）的描述

RAR 技术通过两项关键优化（清空后端和提前启动）来显著提升软错误的可靠性，同时保持与 PRE 相当的性能水平。

1. 清空后端状态（Flush）

PRE 问题：PRE 在运行前执行期间为了减少模式切换的开销，保留了微架构状态（如 ROB、指令队列和寄存器文件），导致这些状态易受软错误影响。而内存访问往往需要数百个处理器周期，这期间微架构状态会暴露给软错误。
RAR 解决方案：RAR 在运行前执行结束时（即从运行前模式切换回正常模式时）清空后端状态。这样，运行前执行期间积累的状态不会受到软错误的影响。即使在此期间发生了位翻转，也不会影响处理器的正确性，从而显著提高了可靠性。
与 Flushing 的对比：RAR 的清空操作与传统的 Flushing 技术不同。Flushing 在缓存未命中时立即清空管道，导致处理器失去了利用 MLP 的机会，从而严重影响性能。而 RAR 则是在内存访问结束后再清空管道，这样不仅能提高软错误的可靠性，还能够利用 MLP 提升性能。

2. 提前启动（Early Start）

PRE 问题：正如前面提到的，PRE 只在 ROB 完全填满时启动运行前执行，导致错失了很多在 ROB 未完全填满时暴露的软错误易感状态。
RAR 解决方案：RAR 提出提前启动运行前执行的优化，即在 ROB 头部被长延迟内存访问阻塞时立即启动运行前执行，而不是等到 ROB 完全填满。
- 对性能的影响：提前启动可能会更频繁地触发运行前执行，从而影响性能。然而，提前启动可能有两方面的性能提升：
  1. 提前启动可以预见未来的 ROB 填满，提前进行预取，可能会加深对未来指令流的预取，从而提高性能。
  2. 提前启动时，处理器后端还有更多可用资源，这也可能延长运行前执行的深度。
- 潜在的性能影响：尽管提前启动可能会提高性能，但频繁的运行前执行也可能带来不必要的开销，特别是在 ROB 没有完全填满的情况下。实验结果表明，提前启动的条件对性能的影响总体上是中性的，但在可靠性上有显著的提升。

ROB：ROB 在流水线的整个执行过程占据着关键位置，用于跟踪未完成指令的状态。图中展示了在运行前模式下，ROB 的部分指令被冻结，不再继续调度新指令。
计时器：这是 RAR 关键的新增硬件组件。每当一个新的指令成为 ROB 头部的最老指令时，计时器设置为 15（即二进制 “1111”），每个周期倒计时。当计时器归零时，意味着这个指令在 ROB 头部停留超过 14 个周期，推测为 LLC 缓存未命中，处理器进入运行前执行模式。
SST 和 PRDQ：这是 PRE 中的组件，SST用于识别导致长延迟加载的指令链，PRDQ用于精确管理寄存器的分配和释放。
RA-Start 和 RA-End：图中标注了运行前执行模式的开始和结束时刻。在运行前执行模式开始时（RA-Start），处理器冻结 ROB 中的指令，并只执行与长延迟加载相关的指令链。模式结束时（RA-End），当阻塞加载返回，处理器清空后端资源并恢复到正常模式。

倒计时计时器：
- RAR 在 ROB 头部添加了一个 4 位倒计时计时器（如图中的 "Timer 1111" 所示），用于跟踪最老的指令在 ROB 头部停留的时间。
- 当计时器归零（停留超过 14 个周期），表明该指令可能遇到了 LLC 缓存未命中，处理器进入运行前执行模式。这种实现方式具有低硬件开销。
运行前执行模式（RA-Start 到 RA-End）：
- 当处理器进入运行前执行模式时，会保存当前的程序计数器（PC）和寄存器分配表（RAT），并冻结部分填充的 ROB。
- 在运行前执行模式中，处理器不再向 ROB 分配新条目，而是只执行与长延迟加载相关的指令链。举例来说，图中展示了加载指令 L1、L2 和 L3 以及它们的生产者指令链（如 A2 – B2，A3 – B3）。
- RAR 使用 PRE 的 SST 和 PRDQ 来识别这些指令链，并管理寄存器的分配。
结束运行前执行模式（RA-End）：
- 当阻塞加载指令返回时，RAR 模式结束（RA-End），处理器清空整个后端，包括 ROB 中的所有指令。这意味着在运行前执行期间可能遇到的软错误不会影响处理器的正确性。
- 处理器恢复到运行前执行模式开始时的状态，包括恢复 RAT 和重新从阻塞加载指令的 PC 处取指，处理器进入正常模式继续执行。

四、实验平台

A. 实验设置

Sniper 6.0 仿真器：

实验采用了 Sniper 6.0 仿真器进行仿真，该仿真器是经过硬件验证的，具有高精度的核心模型。仿真器被增强以跟踪 ACE位，用于衡量 ROB（重新排序缓冲区）、IQ（指令队列）、LQ（加载队列）、SQ（存储队列）、功能单元和寄存器文件中暴露的位数。

NOP 指令（空操作）和错误路径指令不计入 ACE 位。

基线核心配置：

表格 II 列出了实验所使用的基线乱序处理器的配置，包括 192 条目的 ROB，92 条目的指令队列，64 条目的加载队列和存储队列等。这些配置与 Precise Runahead Execution (PRE) 相同，以便进行公平比较。

工作负载选择：

实验使用了来自 SPEC CPU2006 和 CPU2017 套件中的所有内存密集型工作负载，并且选择了具有代表性的 500M 指令的 SimPoints。

基准中 LLC（最后一级缓存）每千条指令的未命中率（MPKI）大于 8 的工作负载被认为是内存密集型的，而 MPKI 小于 8 的被视为计算密集型的。

硬件资源建模：

由于无法找到商业处理器中每个流水线结构条目的精确大小，实验根据表 III 所列的硬件资源大小进行建模。

假设 ROB 条目占用 120 位，指令队列条目占用 80 位，加载队列条目占用 120 位，存储队列条目占用 184 位，整数寄存器为 64 位，浮点寄存器为 128 位。所有的功能单元和缓存都被假设是受错误检测或纠错码保护的。

B. 软错误易感性：度量指标

ACE 分析：

实验使用了由 Mukherjee 等人提出的 ACE 分析来评估处理器对软错误的易感性。

ACE 位：是指必须正确执行以保证程序正确性的位数。ACE 周期表示某个位在正确执行中暴露的周期数。

ACE Bit Count (ABC)：

架构易感性因子 (AVF)：

AVF 表示由正确路径指令暴露的处理器位数的比例，计算公式为：

其中 N 是处理器位数，T 是工作负载的执行时间。

软错误率 (SER)：

SER 是 AVF 的一个函数，表示每单位时间内程序遇到的 ACE 位错误的总数。

MTTF（平均故障间隔时间） 和 FIT（每十亿小时故障次数） 是常用的可靠性指标。MTTF 的计算公式为：

而 FIT 率的计算公式为：

其中，原始错误率由电路技术和环境决定。

图 7 分为两个子图：(a) MTTF（平均故障间隔时间）和 (b) ABC（架构相关的暴露位数）。这两个图用于评估软错误的可靠性。

图 7(a): MTTF

OoO 核心（红色）为基线乱序处理器。
FLUSH（蓝色）通过在内存访问阻塞 ROB 时清空管道，显著提高了 MTTF。在一些基准测试（如 libquantum 和 mcf）上，FLUSH 将 MTTF 提高了 3.2 倍，平均提升 3.2 倍。
PRE（绿色）提升了性能，但对 MTTF 的影响相对有限，平均提升较少。
RAR-LATE（紫色）通过晚启动运行前执行，并在结束时清空管道，实现了比 PRE 更好的可靠性提升，MTTF 平均提升了 2.5 倍。
RAR（橙色）则通过提前启动运行前执行并清空管道，实现了最大的 MTTF 提升。在一些内存密集型工作负载上，如 mcf 和 libquantum，MTTF 提升显著，最高可达 35.8 倍。

图 7(b): ABC

ABC 图中表示的是暴露在软错误下的位数。ABC 越低，代表系统暴露的位数越少，可靠性越高。

OoO 核心在所有工作负载下的 ABC 较高，这意味着暴露在软错误下的位数较多。
FLUSH 显著降低了 ABC，平均减少了 61.4%。
PRE 的 ABC 降低有限，平均减少 28.3%。
RAR-LATE 的 ABC 表现出色，平均减少了 65.5%，比 FLUSH 更好。
RAR 再次表现最佳，ABC 减少了 81.4%，尤其在内存密集型的基准测试上（如 mcf 和 libquantum）效果最显著。

图 8(a): IPC（每周期指令数）

OoO 核心的 IPC 为基线。
FLUSH 的 IPC 下降明显，尤其是在内存密集型基准测试（如 libquantum 和 mcf）中，性能下降最为严重，平均下降 9.3%，在 libquantum 上下降高达 21.9%。原因是 Flushing 清空了管道，极大地限制了内存级并行性（MLP）。
PRE 通过在 ROB 完全填满时启动运行前执行，利用了额外的 MLP，从而显著提升了 IPC，平均提升 38%，最高在 libquantum 上提升 2.5 倍。
RAR-LATE 相对于 PRE 略微有性能损失，平均下降 4.2%，最大下降 8.0%（如 leslie3d 基准测试），因为在切换模式时清空了微架构状态，导致了一定的开销。总体上，RAR-LATE 仍然比 OoO 核心性能提升了 32.7%，在 libquantum 上提升 2.4 倍。
RAR 的性能介于 RAR-LATE 和 PRE 之间。对于那些提早启动运行前执行有利的基准测试（如 fotonik, gems 和 milc），RAR 性能表现更佳，而对于一些不导致 ROB 完全填满的基准测试（如 libquantum 和 roms），性能略有下降。总体上，RAR 平均性能提升 33.5%，在 fotonik 上提升了 2.6 倍。

图 8(b): MLP（内存级并行性）

MLP 图显示了各方案在处理内存密集型任务时的并行内存访问能力。
OoO 核心 能在整个 ROB 中找到独立的内存访问，因此 MLP 较高。
FLUSH 降低了 MLP，因为在内存访问阻塞时清空管道减少了并行访问的机会。
PRE 利用运行前执行，显著提高了 MLP，尤其是在内存密集型工作负载中表现突出。
RAR-LATE 的 MLP 相对较高，接近 PRE，但仍有轻微下降。
RAR 则在 fotonik 等任务中表现出色，利用早启动运行前执行实现了更高的 MLP，但在一些负载下（如 libquantum），由于提前启动时 ROB 并未完全填满，MLP 较低。

表 IV 展示了几种不同运行前执行（Runahead）变体的特性：

Early：是否在长延迟加载阻塞 ROB 时提早启动运行前执行，而不是等到 ROB 完全填满。
Flush：是否在运行前执行结束时清空管道以确保软错误的可靠性。
Lean：是否仅执行那些对未来内存访问有用的指令，而非执行所有未来指令。
TR（传统运行前执行）：在 ROB 完全填满时启动运行前执行，并在结束时清空管道，但执行所有指令。
TR-EARLY：与 TR 类似，但在长延迟加载阻塞 ROB 头部时提前启动。
PRE：仅执行对未来内存访问有用的指令，但不清空管道。
PRE-EARLY：与 PRE 类似，但在 ROB 头部被阻塞时提早启动。
RAR-LATE：在运行前执行结束时清空管道，但运行前执行启动较晚。
RAR：提早启动运行前执行，并清空管道，同时仅执行对未来内存访问有用的指令。

图 9 详细比较了不同 Runahead 变体在平均故障间隔时间（MTTF）、暴露位数（ABC）和每周期指令数（IPC）方面的表现：

MTTF：RAR 具有最高的 MTTF，显著超过 Flushing 和其他 Runahead 变体，表明 RAR 是在软错误可靠性方面最好的方案。
ABC：RAR 也显著降低了暴露位数，表明它在软错误下的状态暴露最少。
IPC：虽然 RAR 的性能稍逊于 PRE，但仍然接近 PRE，并大幅超过其他 Runahead 变体。

图 10 展示了随着 ROB 大小增加，暴露位数（ABC）的变化趋势：

OoO 核心的暴露位数随着 ROB 大小增加显著上升，表明更大的 ROB 会带来更多的软错误暴露。
RAR 则通过提早启动运行前执行和清空管道，有效减少了暴露位数，即使在更大的后端资源配置下，也保持了较低的 ABC，缩小了随 ROB 大小增加导致的可靠性差距。

图 11 分为三个子图，分别展示了在带有硬件预取器的系统上，OoO 基线、PRE 和 RAR 三种方案的 MTTF、ABC 和 IPC 指标的变化。图中包括了两个硬件预取器配置：

+L3：表示在最后一级缓存（L3 缓存）中启用了基于步幅（stride-based）的硬件预取器。
+ALL：表示在所有缓存级别（L1、L2 和 L3）中都启用了基于步幅的硬件预取器。

图 11(a): MTTF（平均故障间隔时间）

在启用硬件预取器后，OoO、PRE 和 RAR 的 MTTF 仍然有所提升，但提升幅度有所减小。
RAR 在使用硬件预取器的配置下，仍然保持了显著的 MTTF 提升。即使在所有缓存级别启用硬件预取器（+ALL）的情况下，RAR 的 MTTF 仍然远高于基线和 PRE，表明 RAR 在处理器可靠性方面依然保持显著优势。

图 11(b): ABC（架构暴露位数）

在 +L3 和 +ALL 配置下，硬件预取器降低了处理器暴露在软错误下的位数，因此 OoO 和 PRE 的 ABC 都有所减少。
RAR 的 ABC 进一步减少，特别是在所有缓存级别启用硬件预取器时（+ALL），它的暴露位数显著低于其他配置。这表明即使硬件预取器减少了一些 LLC 未命中，RAR 仍然能够有效减少软错误暴露位数。

图 11(c): IPC（每周期提交的指令数）

+L3 和 +ALL 配置下，硬件预取器提升了 OoO、PRE 和 RAR 的 IPC，因为预取器能够减少内存访问延迟。
RAR 的 IPC 表现仍然接近 PRE，特别是在所有缓存级别启用硬件预取器时（+ALL），RAR 的性能接近 PRE，表明 RAR 能够在启用硬件预取器时保持良好的性能。