ACE-GPU：解决NTC中阻塞点瓶颈

ACE-GPU：突破NTC阻塞瓶颈

原创于 2025-10-20 16:42:46 发布 · 965 阅读

29 ·

CC 4.0 BY-SA版权

文章标签：

#近阈值计算 #阻塞点 #时序违例

ACE‐GPU：解决近阈值计算GPU中由阻塞点引发的性能瓶颈∗

塔穆雷斯·沙巴尼安、阿特雷·巴尔、普拉巴尔·巴苏、库希克·查克拉博蒂、桑格米特拉·罗伊，犹他州立大学 BRIDGE实验室，电气与计算机工程系，美国犹他州洛根
{tahmoures,aatreyi.bal,prabalb}@aggiemail.usu.edu,{koushik.chakraborty,sanghamitra.roy}@usu.edu

摘要

多核设备在严格热预算下的普及推动了近阈值计算（NTC）的研究。然而，图形处理单元（GPU）在NTC区域的运行仍然鲜有探索。在本研究中，我们探讨了NTC中一个重要的可靠性难题——阻塞点，该问题严重限制了GPU的性能。通过采用跨层方法，我们展示了阻塞点在NTC区域运行的GPU中引发时序错误的显著影响。我们提出了一种全面的电路‐架构解决方案，通过有效应对由瓶颈引起的时序错误，推动高能效NTC‐GPU设计范式的实现。与最先进的时序错误缓解技术相比，我们提出的方案在NTC‐GPU性能和能量延迟积方面分别实现了3.18×倍和88.5%的提升，同时仅带来轻微的面积和功耗开销。

CCS概念
• 硬件 → 物理设计（电子设计自动化）; 时序分析; 超大规模集成电路设计; 功耗与能量;

关键词
近阈值计算，阻塞点，时序违例

ACM引用格式：
塔穆雷斯·沙巴尼安、阿特雷·巴尔、普拉巴尔·巴苏、库希克·查克拉博蒂、桑格米特拉·罗伊。2018。ACE‐GPU：解决近阈值计算GPU中由阻塞点引起性能瓶颈问题。收录于ISLPED ‘18：国际低功耗电子与设计研讨会，2018年7月23日至25日，美国华盛顿州西雅图，詹妮弗·B·萨托、提奥·德洪特和沃尔夫冈·德梅乌特（编）。计算机协会，美国纽约，第4篇文章，共6页。https://doi.org/10.1145/3218603.3218644

1 引言

图形处理单元（GPU）从专用图形芯片发展为通用计算设备，开启了并行计算的新时代。对于高度并行的应用，GPU相比中央处理器（CPU）可提供显著的性能提升。然而，GPU中大量的线程级并行通常伴随着巨大的功耗[15]。为了避免触及功耗墙，同时仍保持并行计算的优势，低功耗GPU已成为当务之急。因此，近阈值计算（NTC）已成为高能效GPU的一种有前景的设计范式[5]。在本文中，我们探讨了工作在NTC区域的GPU（NTC‐GPU）所面临的一个重要可靠性问题。

NTC‐GPU除了具备高能效外，还受到显著的工艺变异（PV）引起的延迟变化影响[19]。此外，由于GPU的芯片尺寸较大，相比CPU更容易受到片内工艺变异的影响[3]。在NTC下，与工作在超阈值（STC）电压的传统GPU相比，流处理器核心数量大幅增加，使问题更加复杂[5]。本文的研究重点是阻塞点——一种由工艺变异引发的NTC‐GPU中的关键性能瓶颈。阻塞点是指电路路径中一小部分受工艺变异影响的逻辑门，它们主导了路径延迟，从而将原本延迟较短的路径转变为关键路径[8]。

阻塞点的形成源于NTC下剧烈的门延迟变化。由于其是制造工艺过程中的产物，在设计阶段无法精确预测或处理[4]。因此，需要一种动态自适应技术来应对已制造芯片中的阻塞点。最近，巴尔等人提出了一种原位时序推测技术，用于在NTC下对简单乱序CPU流水线中的阻塞点引起时序错误进行预测和恢复[4]。

在本研究中，我们表明，将此类错误恢复机制直接应用于单指令多数据1流水线时，并不能像[4]（第5节）那样显著提升NTC性能。因此，采用跨层方法，我们提出了一种针对阻塞点具有弹性的NTC‐GPU架构，称为自适应瓶颈容错GPU（ACE-GPU）。ACE‐GPU利用GPU计算单元（CU）中时序错误的近期历史，采用一种新颖的线程映射策略，以最小化未来时序错误的发生，同时引入极小的开销。据我们所知，这是首个分析NTC‐GPU中由阻塞点引起性能瓶颈，并提出时序错误缓解技术以改善GPU功耗‐性能表现的工作。本工作的主要贡献如下：

我们详细阐述了为何现有的时序错误缓解技术在减轻NTC‐GPU中阻塞点引起的性能损失方面效果甚微（第2.2节）。
我们探讨了在不同工作条件下，现有时序错误缓解机制（第2.4节）下瓶颈点对GPU功耗性能的影响。
我们提出的NTC‐GPU设计范式——ACE-GPU——对基础GPU架构进行了增强，以解决GPU中由阻塞点引发的时序错误（第3节）。
通过一系列通用图形处理器（GPGPU）应用，我们评估了ACE‐GPU相较于传统时序错误缓解技术在性能提升、能效提升以及开销方面的表现（第5节）。

示意图0

2 动机

在本节中，我们阐述了阻塞点作为NTC‐GPU中的一个重要可靠性问题。第2.1节阐明了GPU对由阻塞点引起的时序错误具有显著更高的敏感性。我们在第2.2节讨论了现有时序错误缓解技术的局限性。通过采用跨层方法（第2.3节），我们展示了GPU流水线中由阻塞点引起的延迟变化（第2.4节），并引出了ACE‐GPU的设计动机（第2.5节）。

2.1 背景

由于对工艺变异（PV）更为敏感，NTC系统相比STC系统更容易受到阻塞点引起的延迟变化的影响[4, 6]。此外，Aguilera等人已证明，由于GPU的核心数量远多于传统的多核CPU，其受片内工艺变异的影响更大[3]。为了充分利用通用GPU应用的线程级并行性，NTC‐GPU采用的核心数量多于其STC对应产品[5]。因此，在NTC‐GPU中，由于阻塞点形成而导致时序违例的概率显著增加，从而阻碍了NTC运行所带来的能效优势。

2.2 现有的时序错误缓解技术能否应对GPU中的瓶颈点？

研究人员已提出多种电路‐架构技术来应对CPU和GPU中的时序错误。我们简要讨论为何这些技术在应对NTC‐GPU中由瓶颈点引发的时序错误方面效果有限。

时序保护带 ：巴尔等人已表明，自适应时序保护带技术[17]在应对NTC处理器中由阻塞点引起的时序错误时，能效极低[4]。因此，在NTC‐GPU中采用此类策略对于维持可靠且高效的能量运行也是无效的。
动态错误检测与纠正 ：部署影子锁存器以动态检测时序错误（例如，Razor[10]），并重放出错的指令，是提高系统时序弹性的最流行且有效的技术之一。然而，Razor并未识别电路中的错误模式，而这一点对于有效预测由阻塞点[4]引发的重复性时序错误至关重要。因此，现有的基于Razor的错误检测与纠正技术不太可能在NTC‐GPU中高效应对时序错误。
动态瓶颈感知 ：通过揭示指令元数据与相应被激活的瓶颈点之间的独特关系，巴尔等人最近提出了一种用于NTC处理器的自适应时序错误推测与恢复方案[4]。然而，将巴尔的方法直接应用于NTC‐GPU会导致显著的性能损失（第5节）。这是因为GPU中单个执行单元的时序错误会使整个流水线的所有SIMD通路停顿，从而有效地将错误率乘以并行度。

接下来，我们简要讨论用以展示NTC‐GPU中由阻塞点p引起的延迟变化的方法。

2.3 方法论

我们使用基于AMD的Southern Island GPU架构建模的MIAOW GPU RTL[1]，作为实验平台。为了综合一个计算单元（CU）中的解码与执行单元，我们采用了NanGate提供的15纳米FinFET库[16]。为了对FinFET在标准阈值计算（STC）和近阈值计算（NTC）下的工艺变异（PV）进行模拢单元，我们使用了VARIUS[18]、VARIUS‐NTV[12]和VARIUS‐TC[13]模型。我们采用自研的统计时序分析工具来研究解码与执行单元中敏感路径的延迟情况。为保守估计，我们考虑电路中随机选择的1%门所受工艺变异性引起的延迟。详细的实验方法将在第4节中讨论。

2.4 结果

示意图1 ：瓶颈引起的额外延迟)

图1(a)展示了计算单元解码和执行阶段中由阻塞点引起的额外延迟。延迟值已归一化为相应的无工艺变异情况。以下是来自图1(a)的三个关键观察结果：

阻塞点对不同流水线级的影响各不相同。例如，在0.45V时，解码阶段表现出∼2.8%的额外延迟，而执行阶段的额外延迟为∼18%。这种差异在其他工作电压下也同样存在。本文后续结果均基于执行阶段进行，因其对阻塞点引起的延迟变化更为敏感。
随着工作电压接近近阈值计算电压，阻塞点引起的延迟单调增加。例如，执行阶段在0.45V下的额外延迟相比0.85V时增加了∼4.7×。该结果证实了这一趋势。
在0.85V电压下，解码阶段不存在由阻塞点引起的额外延迟。这是因为阻塞点并不总会在制造电路中产生新的关键路径。

计算单元数量的增加可以通过有效利用GPGPU基准测试的线程级并行性来提升NTC性能[5]。然而，由于阻塞点引起的时序错误会在错误纠正机制中引入巨大的性能惩罚，严重限制NTC的性能。图1(b)展示了当GPGPU基准测试RecursiveGaussian在不同数量的计算单元（利用率为100%）下运行，并采用Razor作为时序错误缓解机制时，性能惩罚的变化情况。针对16、32、64和128个计算单元所考虑的工作电压分别为0.85V、0.65V、0.55V和0.45V。图1(b)中最左侧和最右侧的柱状图分别代表STC和NTC工作条件。结果已归一化为16个计算单元时的性能惩罚。我们注意到，8×计算单元数量的增加使得性能惩罚增加了∼10.8×。该结果揭示了Razor在应对NTC下加剧的由瓶颈点引起的时序错误方面的无效性。

示意图2 ：性能惩罚的变化)

对于相同的实验，图1(c)显示，在NTC（128个计算单元）下相对于STC（16个计算单元）的能耗增加了∼5.3×。NTC下的大部分能耗来自漏电能耗。由于漏电能耗与执行时间成正比，NTC下的高性能损失（图1(b)）削弱了NTC‐GPU的能效优势。

示意图3 ：能耗的变化)

2.5 意义

我们的动机性结果表明，阻塞点对NTC‐GPU的性能以及能耗具有巨大影响。因此，为了高效利用NTC‐GPU中庞大的SIMD资源，我们需要探索一种能够动态预测并避免计算单元中即将发生的时序错误，同时带来最小性能和功耗开销的设计范式。接下来，我们探索了一种全新的GPU设计范式，该范式重新获得了近阈值计算的能效优势。

3 自适应瓶颈容错GPU（ACE‐GPU）

在本节中，我们讨论ACE‐GPU，一种用于解决NTC‐GPU中由阻塞点引起的时序错误的新型设计范式。我们在第3.1节中介绍了设计概述，并在第3.2节中详细阐述了设计组件。

3.1 设计概述

示意图4

图2展示了ACE‐GPU的概念概览。超线程调度器（UTD）是GPU的一个关键组件，负责将线程块分配给计算单元[20]。在ACE‐GPU中，我们将UTD的基础线程块分配策略更改为瓶颈感知分配策略。这种方法与通过阻塞线程块执行来避免即将发生的时序错误[4]有着本质区别。我们对基础GPU架构进行了增强，添加了瓶颈错误监测单元(CMU)和黑名单单元(BLU)。

CMU负责识别、纠正和预测由阻塞点引起的时序错误。CMU的主要组成部分包括瓶颈错误感知表(ChEST)、决策单元接口(DUI)和阈值比较器。另一方面，BLU与CMU和UTD协同工作，用于检测并避免严重受到阻塞点引起的时序错误影响的计算单元。接下来将描述CMU和BLU的不同组件及其各自的工作原理。

3.2 ACE‐GPU组件

CMU和BLU动态监控不同计算单元中发生的时序错误，并与线程块分配器通信，以实现高效的线程块分配，从而提升NTC‐GPU性能。

3.2.1 瓶颈错误监测单元 (CMU)

CMU接收来自各个计算单元的时序错误详细信息，并记录这些信息以供将来参考。然后，它将受阻塞点严重影响而变得不可靠的计算单元的IDs填充到BLU中。接下来将解释CMU各组件的作用。

瓶颈错误感知表（ChEST） ：ChEST以出错的操作码元组形式记录每个计算单元中发生错误的情况。在我们的实现中，每个元组对应一个计算单元ID、该计算单元遇到的三个出错的操作码及其出现次数（即该操作码在计算单元上执行的次数，而非其导致的时序错误次数）。此外，每个元组还包含总错误数，用于记录在该计算单元中检测到的时序错误数量。

ChEST被实现为内容可寻址存储器（Content Addressable Memory, CAM），以支持表查找。ChEST中的条目数量需要在相关开销与感知重复出现的时序错误的准确性之间进行权衡。较大的条目大小可确保相对较高的感知精度，但会带来相对较高的面积和功耗开销。另一方面，较小的ChEST会降低感知精度，从而增加产生的惩罚周期。在我们的评估中，ChEST的条目大小设置为10（针对128个计算单元）。线程块分配器（UTD）在将线程块分配给计算单元之前会查找ChEST，以避免即将发生的重复时序错误。

决策单元接口(DUI) ：DUI负责管理CMU内部的错误感知和错误纠正。算法1展示了DUI的工作原理。当接收到计算单元传来的时序错误信息后，DUI会更新ChEST中记录的已发生错误。这些错误通过双采样锁存器[10]进行检测。DUI将出错的操作码及其对应的计算单元ID记录在ChEST中。如果该ID已在ChEST中列出，则DUI将操作码记录到ChEST中对应的元组内。如果该元组已经…

算法1 DUI的工作原理
1: procedure 动态微调单元(时序信息[IDs][操作码]) 2: for all IDs ∈ timing_info do 3: if (标识符 ∈ ChEST) then 4: if (timing_info[标识符][操作码] ∈ ChEST[标识符]) then 5: ChEST[标识符][操作码].计数++ 6: else 7: if (操作码字段.full()) then 8: opcode_field.驱逐(least_occurring_opcode) 9: end if 10: opcode_field.insert(操作码) 11: end if 12: else 13: ChEST.逐出伪LRU(标识符) 14: ChEST[ID][opcode].计数 = 1 15: ChEST[ID].错误计数++ 16: end if 17: PDCP(标识符) 18: end loop 19: end procedure

当ChEST满时，新的错误操作码会替换出现次数最少的现有操作码。同时，DUI会更新相应计算单元的总错误计数。如果ChEST已满，新的计算单元ID可以使用伪LRU策略替换ChEST中现有的计算单元。一旦在计算单元中检测到错误，DUI将暂停该计算单元的当前执行，并重新分配线程块以确保无错误执行（第3.2.3节）。

为了适应高错误率的情况，DUI采用了性能下降控制过程(PDCP)，如算法2所述。当BLU中的计算单元数量超过总计计算单元数的10%时，DUI会提高阈值比较器所采用的阈值。随后，它会刷新BLU中现有的条目，并存储此次刷新BLU所对应的当前阈值。该存储的阈值用于计算总的时序错误数量，以防止被刷新的计算单元再次出现在ChEST中。如果当前阈值已超过预设最大值，则不再增加。在这种情况下，ChEST中一个总错误数超过当前阈值的计算单元可以随机替换BLU中的一个现有计算单元。然而，在我们的仿真中尚未遇到这种情况。

阈值比较器 ：阈值比较器持续监控ChEST中所有计算单元的总错误计数。一旦某个计算单元的总错误数超过比较器中预设的阈值，该计算单元ID将从ChEST中移除，并加入BLU。在我们的实现中，如果被黑名单的总计算单元数达到一定比例，我们会动态更新阈值。然而，阈值不能超过预设的上限。

算法2 性能下降控制过程
1: procedure PDCP(ID) 2: 错误计数 = ChEST[ID].错误计数 + 1 3: if (BLU[ID].标签 == 0) then 4: 错误计数 += BLU[ID].旧误差阈值 5: end if 6: if (error_count > error_threshold) then 7: if (BLU.size() == 0.1 * total_num_CU) then 8: if (error_threshold < max_error_threshold) then 9: for IDs ∈ BLU do 10: if (BLU[ID].tag == 1) then 11: BLU[ID].标签 = 0 12: BLU[ID].旧误差阈值 = 误差阈值 13: end if 14: end for 15: 误差阈值 += delta_threshold 16: else 17: BLU.randomReplaceCU(ID) 18: end if 19: end if 20: BLU[标识符].标签 = 1 21: ChEST.evict(ID) 22: end if 23: end procedure

3.2.2 黑名单单元(BLU)

BLU会记录总错误数超过给定错误阈值的计算单元ID。任何列在BLU中的计算单元ID都不会被考虑用于线程块分配。UTD在将线程块分配给计算单元之前，会查询BLU。BLU的大小固定为计算单元总数的10%（通过经验确定）。如果被列入黑名单的计算单元数量超过BLU的容量，则通过将所有计算单元ID的有效标签置零来清空BLU，并在比较器中提高阈值。与ChEST类似，BLU也是以内容可寻址存储器(CAM)的形式实现的。

3.2.3 超线程调度器(UTD)

我们修改了基于轮询的UTD，使其与CMU和BLU协同工作。算法3展示了重构后的UTD分配方法。首先，我们将每个线程块视为仅包含一种操作码类型的SIMD线程[14]。其次，在将线程块分配给计算单元之前，UTD会查询BLU。若某计算单元出现在BLU中，则该计算单元会被UTD排除。接着，UTD在ChEST条目中搜索该计算单元。当找到匹配项时，只有当ChEST中对应计算单元的元组不包含当前待分配线程块的操作码时，该计算单元才会被考虑用于线程块分配。如果该条件不满足，UTD则从剩余的计算单元池中随机选择一个。当线程块在某个计算单元中遇到时序错误时，UTD会根据算法3重新调度出错的线程块。重新调度线程块会产生性能惩罚，其大小由GPU的流水线级数决定。

算法3 UTD分配

1: procedure UTD(BLU, ChEST)
2:   ID列表 = [1,...,128]
3:   for 标识符 ∈ ID列表 do
4:     操作码 = 待分配的操作码
5:     if 标识符 ∈ BLU then
6:       next
7:     end if
8:     if 标识符 ∈ ChEST && 操作码 ∈ ChEST[标识符] then
9:       next
10:    end if
11:    标识符.assign(操作码)
12:    跳出
13:  end for
14: end procedure

我们在评估中考虑了ACE-GPU组件的性能和硬件开销（第5节）。

4 方法

在本节中，我们描述了用于实现和评估ACE‐GPU的综合性跨层方法。

4.1 设备层

我们通过模拟基本逻辑门（与非门、或非门、反相器）的HSPICE模型，来估计它们在存在情况下的延迟分布参数。我们使用16纳米预测技术模型（PTM）进行仿真。为了估算由随机和系统性变化引起的片内工艺变异（PV），我们分别采用VARIUS[18]和VARIUS‐NTV[12]模型用于标准阈值计算（STC）和近阈值计算（NTC）。此外，我们利用VARIUS‐TC模型来引入FinFET特性[13]。我们执行蒙特卡洛仿真，以评估每个逻辑门10,000个实例的传播延迟变化。这些延迟值将在电路层（第4.2节）中用于实现电路中的瓶颈点。

4.2 电路层

在这一层中，我们执行两个主要任务。首先，我们对一个开源参考GPU RTL[1]进行扩展，以实现所提出的ACE‐GPU架构的组件。我们使用Synopsys Design Compiler[7]对参考和扩展后的GPU RTL进行综合。综合时考虑的STC和NTC下的VF值分别为（0.85V，900MHz）和（0.45V，400MHz）。其次，我们将综合后的网表和输入向量（第4.3节）输入到自研统计时序分析（STA）工具中。该STA工具包含从HSPICE仿真（见第4.1节）获得的不同工作电压下基本逻辑门的延迟分布库。该工具对电路网表中给定输入向量下的敏感路径进行时序分析。由此，我们能够清楚地了解阻塞点对制造出的芯片在运行时路径延迟的影响。我们利用生成的延迟报告来评估对比方案的有效性（第5.1节）。

4.3 架构层

我们在Multi2Sim架构模拟器[20]中对AMD SouthernIsland GPU进行建模。本文所考虑的GPU架构参数列于表1中。我们修改Multi2Sim代码库，以在运行AMD的APP SDK套件中的GPGPU基准测试[2]时，从执行单元自动提取逐周期的指令元数据（即操作码和操作数）。这些元数据作为STA工具的输入向量进行动态路径敏感化分析，并评估瓶颈点的影响（第4.2节）。

表1：NTC-GPU配置
| 参数 | 配置 |
| — | — |
| 计算单元数量 | 128 |
| 供电电压 | 0.45V |
| 计算单元频率 | 400MHz |
| 二级缓存 | 8×768KB，延迟：20 ns |
| 全局内存 | 带宽：264 GB/s，延迟：∼300ns |

5 实验结果

在本节中，我们将比较NTC下的ACE‐GPU相对于其他GPU时序错误恢复方案的性能和能效优势。第5.1节介绍了我们的对比方案，而第5.2、5.3和5.4节分别讨论了在8个GPGPU基准测试中各方案的错误比较、相对性能和能效。第5.5节展示了ACE‐GPU设计的硬件开销。

5.1 对比方案

Razor ：这是一种流行的时序推测技术，通过激进地削减时序保护带来允许流水线中出现间歇性时序错误[10]。这些错误通过在流水线边界处使用双采样锁存器进行检测，并触发线程块重新分配以纠正时序错误。
动态阻塞感知（DCS） ：该方案提供由阻塞点引发的时序错误的检测、纠正以及预测[4]。该方案最初为标量CPU流水线提出，我们将其应用于GPU等向量处理器。DCS采用一种以RAM形式实现的查找表（LUT），用于存储和查找重复出现的时序错误。通过阻塞控制器来管理错误的检测、纠正和预测。在错误避免方面，阻塞控制器在流水线中插入一个停顿周期，使出错的操作码能够完成执行而不产生错误。我们的方案（ACE‐GPU）与DCS有本质区别，因为DCS会stall整个计算单元一个完整周期，而我们则采用了一种高效的线程块映射策略，以实现无错误执行。
自适应阻塞容错GPU（ACE） ：这是我们提出的一种方案，该方案也采用双采样锁存器来检测时序错误。ACE旨在缓解NTC‐GPU中由阻塞点引起的时序错误。ACE的设计在第3节中进行了描述。

5.2 错误比较

示意图5 ：错误比较（越低越好）)

图3(a)展示了不同对比方案下各基准测试所遇到的时序错误相对数量。Y轴的数值是相对于Razor[10]的时序错误数量进行归一化的。ACE中高效的错误预测和线程块分配策略，相较于Razor和DCS，显著减少了时序错误事件的数量，跨所有基准测试。某些基准测试中DCS与ACE之间的时序错误数量存在较大差异（例如，ScanLargeArrays中的∼12.6×），这是由于ACE中ChEST的拓扑结构比DCS中的查找表更高效所致。

5.3 性能比较

示意图6 ：性能比较（越高越好）)

图3(b)展示了对比方案的相对性能。结果以Razor的性能为基准进行了归一化。我们注意到，在所有GPGPU基准测试中，ACE的平均性能比Razor高出3.18×。DCS的性能优于Razor，因为后者由于缺乏错误预测机制而遭遇显著更多的时序错误，导致严重的性能损失。另一方面，ACE的性能明显优于DCS（平均高出1.81×）。原因如下：

(a) ACE采用了一种高效的线程块到计算单元映射策略，避免了为防止时序错误而引入单个停顿周期。
(b) ACE中的BLU能够防止将线程块分配给受瓶颈点严重影响的计算单元。例如，在MatrixMultiplication中，许多计算单元受到瓶颈点的严重影响，因此被列入BLU中。然而，DCS缺少类似BLU的定制化硬件单元，更容易受到阻塞点引起的性能损失影响。
(c) 与Razor中基于RAM的查找表不同，ACE使用基于内容可寻址存储器的查找表（ChEST）来记录近期时序错误的历史，从而实现更快的查找。

5.4 能效比较

我们使用能延积（EDP）指标来衡量各方案的能量效率。图3(c)展示了各方案的EDP，已归一化为Razor方案的EDP。我们提出的方案ACE能量效率最高，在EDP上平均比Razor提升了∼88.5%。必须指出的是，ACE硬件的相对功耗比DCS和Razor高出一个数量级。然而，ACE显著的性能增益足以抵消这一较高的功耗。此外，在近阈值计算（NTC）条件下，总能耗中有相当一部分来自漏电能耗，而漏电能耗与应用程序执行时间成正比。由于ACE中由阻塞点引起的时序惩罚最小（第5.3节），因此在所有基准测试中，ACE显著改善了NTC‐GPU的漏电能耗。这些性能和能耗优势共同促进了EDP的提升，使得ACE成为一种在NTC下极具能效的GPU设计范式。

示意图7 ：能延积比较（越低越好）)

5.5 硬件开销

ACE‐GPU的面积和功耗开销在近阈值计算（NTC）工作条件下通过综合得到，分别为1.42%和6.17%。这些开销是相对于无时序错误缓解机制的基准计算单元（CU）的相应值计算得出的。我们在能延积（EDP）的评估中考虑了功耗开销。

6 相关工作

与我们的工作相关的近期研究大致可分为两类：（a）NTC下CPU核心的性能和可靠性分析，以及（b）在NTC下运行的GPU的性能和可靠性问题。在第一类中，德雷斯林斯基等人探讨了NTC运行的瓶颈及机遇[9]。卡尔普祖库等人研究了工艺变异对NTC系统的影响[11]。工艺变异在NTC下带来的一项显著可靠性问题是阻塞点[8]。巴尔等人已对此问题进行了研究，提出了一种自适应技术，以缓解在近阈值计算（NTC）下运行的单核CPU中由阻塞点引起的时序违例[4]。在第二类方法中，巴苏等人提出了自适应冲刺技术，以缓解工艺变异（PV）导致的NTC‐GPU性能波动[5]。然而，据我们所知，我们的工作是首个探索瓶颈点对NTC-GPU性能和能效影响的研究。

7 结论

在本研究中，我们提出了ACE‐GPU——一种新颖的GPU设计范式——用于应对近阈值计算（NTC）下的阻塞点引发的性能瓶颈。通过采用跨层方法，我们表明，与基于Razor的时序错误检测与纠正机制相比，ACE‐GPU在性能和能延积（EDP）方面分别实现了3.18×倍和88.5%的提升，同时仅引入了微小的硬件开销。