文章目录

  • 零、前言
  • 一、CASINO Core Microarchitecture:使用级联有序调度窗口生成无序调度
    • 0. 摘要
    • 1. 介绍
    • 2. 背景与动机
      • 2.1 有序调度
      • 2.2 无序调度
      • 2.3 InO + 投机式InO调度
    • 3. CASINO 核心微架构
      • 3.1 Baseline Stall-on-Use In-Order Core
      • 3.2 Realizing Speculative InO Scheduling
      • 3.3 Details of CASINO Core Microarchitecture
    • 4. 关于 CASINO CORE的讨论
    • 5. 实验方法
    • 6. 结果与分析
      • 6.1 性能
      • 6.2 寄存器重命名的效果
      • 6.3 内存消歧的效果
      • 6.4 Area Overhead and Energy Consumption
      • 6.5 Design Space Exploration
      • 6.6 Toward Wider Superscalar
    • 7. 相关工作
    • 8. 总结
  • 二、我的阅读过程
    • 1. 微架构的解释
    • 2. 乱序执行的解释
    • 3. 内存级并行与指令级并行的解释

一、CASINO Core Microarchitecture: Generating Out-of-Order Schedules Using Cascaded In-Order Scheduling Windows

零、前言

  1. 原文下载地址:https://ieeexplore.ieee.org/abstract/document/9065575
  2. 下面第一部分为翻译内容。翻译方式:CopyTranslator | 手工。翻译不靠谱,以原文为准。
  3. 我是个外行人,看不懂。顺手放上来吧。

一、CASINO Core Microarchitecture:使用级联有序调度窗口生成无序调度

0. 摘要

有序(InO)内核与无序(OoO)内核之间的性能差距来自动态创建高度优化的指令发布(issue)调度(schedules)的能力。 在这项工作中,我们观察到,通过向传统的InO内核添加一个小的推测性指令调度窗口(即SpecInO) ,也可以实现OoO调度的大量性能优势。 SpecInO在传统的InO调度窗口之前监视一小组指令,目的是在等待时间延迟后发出准备好的指令。 仿真结果表明,SpecInO捕获并发出了超出程序顺序的62%的动态指令。为此,我们提出了一个CASINO核心微体系结构,该结构使用CAScaded IN-Order调度窗口动态地推测性地生成了具有接近InO复杂性的OoO调度。 推测性IQ(S-IQ)如果已准备就绪则发出指令,否则将其传递给下一个IQ。 在最后一个IQ上,指令沿着串行依赖链按程序顺序进行调度。 最终效果是通过级联InO IQ之间的协作进行OoO调度。 为了以最小的成本开销支持推测执行,我们提出了一种新颖的寄存器重命名技术,该技术仅将自由的物理寄存器分配给S-IQ发出的指令。 所提出的内核通过扩展InO内核中已经存在的存储缓冲区,通过提交时值检查来执行动态内存消歧。 我们通过过滤推测负载执行的冗余关联搜索来进一步优化能源效率。 在我们的分析中,相比于InO内核,CASINO内核的性能提高了51%(在OoO内核的10个百分点之内),与InO和OoO内核相比,其能源效率分别提高了25%和42%。

1. 介绍

有序(InO)内核由于其低复杂度和高能效而被广泛使用,但性能有限。 这是因为InO调度的性质导致错过了利用指令级并行性(instruction-level parallelism,ILP)和内存级并行性(memory-level parallelism,MLP)的机会。 无序(OoO)内核通过动态构造所有运行中指令的数据依赖关系图并根据源操作数和执行资源的可用性对其进行重新排序,从而克服了这些限制。 为了支持OoO调度,当今的处理器配备了唤醒/选择和内存消除歧义方案。 众所周知,这些方案占了OoO核心功耗的很大一部分,因为发布队列(issue queue, IQ)和加载/存储单元(load/store unit, LSU)由大量多端口内容可寻址存储器(content addressable memories, CAM) 和随机存取存储器 (random access memories, RAM)组成,并由每个指令多次访问。

数十年来,研究人员试图通过解决调度逻辑的复杂性或减少对耗电大的结构的访问,来使OoO内核更加节能。最近,引入了一种替代方法来提供高性能,同时又保持较低的能耗:使InO核心管道能够实现类似于OoO的执行。根据他们如何生成OoO调度表,可以将该方法大致分为两组。 第一组利用了以下观点:OoO核心花费大部分时间重复生成相同的计划。 因此,通过记住由OoO执行引擎创建的发布计划,并在InO引擎上重播存储的计划以进行将来的迭代,InO管道可以实现接近OoO的性能。 这些方案可以显着提高性能,但是如果没有OoO引擎就无法实现。 此外,在InO引擎上正确重播已记忆的调度表并非易事,因为此类调度表是在OoO引擎上假设寄存器重命名,分支预测和内存歧义化的前提下生成的。

第二组依赖于切片,每个切片都是沿着串行依赖性链提取的。 使用多个并行IQ ,对性能至关重要的片中的指令进行了调度,但与应用程序的其余部分无关。 这实际上是OoO调度的一种受限形式。 然而,基于切片的方法可能会经历严重的减速,因为依赖链的各种形状和大小可能会阻碍在此类并行InO调度窗口中对ILP和MLP的利用。

综上所述,到目前为止,已发现的体系结构要么复杂度高,要么性能有限,这是因为InO管道本身无法生成针对底层微体系结构优化的动态发布调度。 此外,生成的发射(issue)调度(schedules)无法对InO执行引擎上的意外动态事件(例如,缓存丢失和分支错误预测)做出反应,这说明了OoO执行的不可忽视的性能优势

为了解决这些问题,我们探索了一种不同的方法,称为SpecInO,即调度窗口通过检查程序顺序中的动态指令来推测性地发布准备执行的指令(issues ready-to-execute instructions)。 在每个周期中,SpecInO都会检查比在常规InO IQ头上搁置问题的指令年轻的一些指令。 如果检测到一些准备执行(ready-to-execute)的指令,则会立即发出它们。 否则,SpecInO将转向更年轻的指令。 此关键功能可防止SpecInO暂停待处理的长等待时间操作,从而允许按程序顺序调度更多指令。 最终结果是,SpecInO有效地公开了ILP和MLP,同时对动态事件(例如缓存未命中)做出了适当的反应。 仿真结果表明,SpecInO将InO内核的性能提高了49%。

为此,我们提出了一种CASINO核心微体系结构,该体系结构通过以经济高效的方式实现SpecInO的概念,动态生成针对底层InO管道优化的OoO issue schedules。 从2个使用时完好的InO内核开始,我们首先将IQ分为两部分:推测性IQ(Speculative IQ , S-IQ)和常规IQ。SIQ是先进先出(FIFO)队列,用于在其头部调度准备执行的指令。 但是,它不会因属于涉及长延迟操作的依赖关系链的指令而停顿; 相反,它仅将这些指令转发给IQ,并在IQ中按程序顺序对其进行调度。 因此,由于两个InO调度窗口之间的协作,指令可以被捕获并不按顺序发出。 为了以最小的开销支持推测执行,仅将物理寄存器分配给S-IQ发出的指令。 此外,通过节能的内存消歧技术,可以推测性地执行内存操作。 所提出的方法基于提交时的值检查,该方法通过延迟从旧店到仓库的装载推测的验证,消除了对装载队列(LQ)进行关联搜索的需要。 提交推测的负载本身。 在我们的设计中,通过使用简单的计数器数组跟踪未完成的存储地址,在负载的发布和提交时减少了存储队列(SQ)上的关联搜索,从而进一步优化了该技术。

本文的贡献如下:

  • 我们发现OoO调度的大多数好处可以通过按顺序检查一小组指令来实现,而不必等待所有先前的数据依赖关系得到解决。 基于此观察,我们设计了一个节能的核心微体系结构,该体系结构通过使用级联的InO IQ来动态地和推测性地生成OoO计划。
  • 我们提出了一种经济高效的节能寄存器重命名和内存歧义消除方案,它们非常适合所提出的指令调度机制的关键设计理念
  • 我们通过详细的仿真评估了提议的核心微体系结构,并证明它可以替代高性能的OoO处理器(IPC(instructions per cycle)在10个百分点内,能源效率提高42%)的良好替代方案。 我们还证明了CASINO核心可以轻松地扩展到更广泛的问题设计,实现NearOoO性能,同时保持接近InO设计的复杂性和能效。

2. 背景与动机

在本节中,我们将研究InO和OoO调度方案以及ILP和MLP对性能的影响。第五部分描述了核心和内存子系统的配置。为此,我们提出了推动这项工作的主要直觉:通过向InO管道补充推测性InO调度功能,可以实现主动OoO调度的好处

2.1 有序调度

图1说明了每个调度方案如何唤醒并发出指令。 我们假定准备发布i1,i5,i7和i9,并且相应的执行资源(例如,功能单元(FU)或LSU(加载存储单元))可用。在InO调度下(图1a),检查了N个最旧的指令,其中N表示发布宽度(在此示例中设置为2)。 当没有源操作数的指令到达IQ的头部时,我们的基线(使用中的InO内核)将停止。 因此,只有i1可以发布; i2和后面的指令应等待,直到解决了i2的数据依赖性。 最坏的情况是i2读取长等待时间指令产生的值,例如高速缓存丢失负载。 在这种情况下,只有在为内存请求提供服务并发出所有先前的指令后才能发出i5。 这种限制导致错失了并行执行独立(但不连续)指令的机会,从而导致相当低的性能。

2.2 无序调度

在每个周期中,完整的OoO调度检查所有运行中指令之间的依赖关系,并发出不按程序顺序执行的准备执行指令(图1b中的i1和i5)。 通过消除顺序问题带来的限制,OoO内核可以有效地利用ILP和MLP,并比InO内核获得68%的性能提升(图2)。 为了支持OoO执行并保留顺序的程序语义,最新的OoO内核配备了以下架构功能,这些功能通常通过复杂而耗电的结构来实现。

(1)Dynamic Scheduling(动态调度): 动态调度的主要目标是尽快发布可立即执行的指令。重命名后,指令将分派到指令窗口,在该窗口中它们将无序执行并按原始程序顺序提交。 此类未提交的指令由IQ调度,该IQ由唤醒逻辑,选择逻辑和有效负载RAM组成。 唤醒和选择逻辑负责检查未提交指令的源操作数的准备情况并选择要发出的候选对象。 有效负载RAM包含有关正在等待调度的指令的信息。 在整个本文中,我们假设OoO IQ由CAM类型的唤醒逻辑和带有年龄矩阵(最旧优先选择)的前缀和电路选择逻辑组成,而没有压缩电路(随机队列)。

(2)Register Renaming(寄存器重命名):为了消除错误的依赖关系(即写后写(WAW)和读后写(WAR)),同时在动态调度下保持精确状态,OoO内核采用了寄存器重命名。重命名逻辑为具有目标操作数的每个指令分配一个空闲的物理寄存器。 通过读取寄存器别名表(RAT)中的架构到物理的映射,可以重命名源操作数。 寄存器重命名非常简单有效,但是需要大量的物理寄存器(通常等于体系结构寄存器和运行中指令的数量之和),以避免由于缺少可用的物理寄存器而导致调度停顿。

(3)Memory Disambiguation(内存消歧):现代的OoO内核通过推测性地在具有未解析地址的较早存储之前发布负载来对存储操作进行重新排序。LSU支持内存消除歧义,该LSU由LQ,SQ和存储缓冲区(SB)组成。 LQ和SQ分别跟踪未提交中的负载和存储,直到准备好提交为止。 提交的存储位于SB中,直到通过更新L1数据缓存将其从管道中退出为止。

LQ,SQ和SB被实现为FIFO CAM结构。 每个LQ条目都保存相应负载的目标地址。 每个SQ / SB条目都包含目标地址和将被写入存储器的数据。 发出负载后,它访问L1,同时使用其目标地址搜索SQ和SB,以从最新存储(按程序顺序)到相同地址获取值。 如果存在匹配项,则将SQ或SB中的数据直接转发到负载,从而无需等待所有较旧的存储区解析目标地址并更新内存。 否则,将使用来自L1的数据。 计算商店的地址时,商店会搜索LQ以匹配年轻的和推测执行的负载。 如果存在匹配(即违反内存顺序),则会从管道中清除此类过早服务的负载和所有后续指令,然后再次获取。

总而言之,当前的技术水平以及蛮力方法是,调度逻辑监视所有未提交的指令之间的依赖关系,并在每个周期发出就绪指令。 这需要对IQ和LSU进行大量关联搜索,从而占了OoO核心能耗的大部分。

2.3 InO + 投机式InO调度

为了弥合InO和OoO内核之间的性能和能效差距,我们通过在常规InO内核上添加一个小的推测性调度窗口(即SpecInO)来探索替代的调度程序设计。 SpecInO不会检查大型调度窗口中的所有运行中指令,而只会检查具有以下关键功能的少数指令:1)如果发现准备执行的指令,则会立即发出此类指令; 2)否则,它会转向较年轻的说明。 最终结果是,准备好立即执行指令,而其他指令则按照必须遵循的串行依赖关系链进行调度。 作为说明性示例,在图1c中,SpecInO检查[i4 – i5]并发出i5,而不是等待发出较旧的未就绪指令。 然后,SpecInO超越了i5来检查[i6 – i7]。 较早的未就绪指令([i2 – i4])按程序顺序安排在IQ头上。

图2展示了SpecInO的性能潜力,假设正确重命名了指令并且正确更新了架构状态。 每种模型都表示为SpecInO [WS,SO],其中“窗口大小(WS)”是一个周期中检查的指令数,而“滑动偏移量”(SO)是SpecInO在未检测到任何指令的情况下移动的IQ条目数。 问题。 为了区分ILP和MLP对性能的贡献,我们允许SpecInO仅发布非内存指令(非内存),或者发布内存和非内存指令(所有类型)。 在这些模拟中,我们有两个主要观察结果。 首先,SpecInO [2,2]模型显示了一些性能改进,但比SpecInO [2,1]模型的性能要差。 这是因为SpecInO [2,1]有更多机会进行投机问题。 SpecInO [2,2]在找不到准备执行的指令时滑动得太快,即使较年轻的指令在下一个周期已准备就绪,SpecInO [2,1]也可以捕获。 退出SpecInO [2,2]的指令应等待,直到它们到达IQ头,这将大大降低总体发出率。此后,我们仅考虑SpecInO [2,1]模型。

第二个观察结果是,利用MLP对于实现近OoO性能至关重要。 图2显示SpecInO(非内存)通过利用ILP超越了长延迟操作而实现了33%的性能提升,但其性能仍然比OoO调度低得多。 这是因为SpecInO(Non-mem)不允许以推测方式发布加载和存储,因此,直接或间接依赖于它们的指令无法发布,直到它们的生产者在IQ头发布并完成执行。 换句话说,禁用内存操作的推测性问题会阻止对ILP的利用。消除此约束,可以额外提高16个百分点的性能,这在OoO调度的11个百分点之内。

SpecInO显着提高性能的原因可归纳为以下几点:1)通常,未发布的离开SpecInO的指令与其在IQ中的生产者之间的距离(即IQ条目数)很短( 平均0.8条目)。 因此,这种指令很可能在生产者完成执行后立即在IQ的前面发布; 2)SpecInO按顺序检查和发布指令(即从旧到新的指令),隐式地执行最旧优先的调度方案,该方案通常表现出比其他方案更好的性能。

3. CASINO 核心微架构

本节介绍了一个CASINO核心微体系结构,该体系结构为实现SpecInO调度提供了详细的体系结构支持。 我们首先简要介绍一下基线使用中的InO内核。 然后,我们提出了一种低成本,复杂度高的机制,可以在保留精确异常的同时实现OoO调度。

3.1 Baseline Stall-on-Use In-Order Core

在获取并解码之后,指令将分派到IQ,在此等待直到所有先前的依赖关系解决。 使用使用中的停顿策略时,流水线不会因长等待时间指令(例如,缺少缓存的负载)而停顿; 连续发出以下指令,直到由这种长等待时间指令产生的值的使用者到达IQ机头为止。 因此,暂停使用策略通过允许发布独立指令和OoO完成,有效地隐藏了长等待时间操作。 计分板(SCB)保持正确的执行。 SCB的作用是双重的:1)通过强制执行InO写回指令来保留精确的异常; 2)跟踪每个目标寄存器的状态,并检查数据相关性以允许发布独立的指令。 SCB提交的存储将保留在SB中,直到到达SB头为止。 然后,当相应的缓存行具有写入权限时,将存储退出,并将其数据写入L1。 此后,术语“基线”是指基线使用中的InO核心停转。

3.2 Realizing Speculative InO Scheduling

(1)Speculative Issue: 实现SpecInO的一种复杂性有效的方法是将常规IQ分为两部分:推测IQ(S-IQ)和常规IQ(图1d)。依次检查每个队列开头的指令。 但是,S-IQ不会等待其指令准备就绪。 而是仅将这样的未就绪指令传递给IQ1。 换句话说,SIQ充当了IQ的过滤器。 如果一条指令在S-IQ的调度窗口(图1d中的i5)内准备就绪,则会立即发出,并且不会在IQ中再次调度。 如果尚未准备就绪(图1d中的i4),则将指令传递给IQ并按程序顺序进行调度。 这样,可以从S-IQ发出长等待时间延迟后面的指令,而无需等待所有先前的依赖关系得到解决。

(2)Register Renaming:动态重排指令的源和目标操作数需要重命名以消除错误的依赖性。 一个简单的解决方案是为每个目标操作数分配一个新的物理寄存器,以保证通过物理寄存器文件(PRF)在指令之间进行正确的数据通信。 然而,应用常规的寄存器重命名方案需要大量的物理寄存器,从而导致额外的面积和能量开销。在这项工作中,我们利用传递给IQ的指令是按程序顺序进行调度的事实,采取了另一种方法:跳过将空闲的物理寄存器分配给非推测性发布的指令。这些指令是从IQ上一次发出和执行的,因此,即使其中一些更新了相同的体系结构寄存器,也无需分配新的物理寄存器。 可以通过在基线中使用SCB消除由OoO完成而引起的WAW危害(第III-C3节)。 通过向S-IQ发出的指令分配空闲的物理寄存器,可以消除IQ和S-IQ发出的指令之间的WAR依赖性。

(3)Memory Disambiguation:为了实现近乎OoO的性能,必须无序执行内存操作(第II-C节)。 然而,采用常规的硬件存储器消除歧义技术太昂贵,并且可能在期望的功率预算上增加功耗。 解决此问题的一种简单方法是等待所有先前的存储解析目标地址,然后发出以下负载,从而消除了对关联LQ搜索的需要。 但是,如果地址生成指令(AGI)属于涉及一个或多个长等待时间指令的依赖链,则此方法可能会大大降低性能。 在这项工作中,我们采用了提交时值检查,该检查在没有LQ的情况下进行了消歧。 这种方法的关键见解是,不需要通过要发布的商店的关联LQ搜索来实现负载推测的验证。 而是将验证的责任转移到推测的负载本身上; 通过搜索SB并在提交时重播负载,然后重新检查已加载的值。 请注意,我们的基准已经有了SB来缓冲提交的存储。 因此,可以通过扩展现有的SB来同时保留运行中的和已提交的存储,从而轻松地应用此方案。

3.3 Details of CASINO Core Microarchitecture

(1)Overview of CASINO Core Pipeline:图3表示了基于2个InO核心构建的CASINO核心流水线。 为了支持SpecInO调度,将IQ分为两个单独的部分:S-IQ和常规IQ。 新添加了重命名逻辑(包括RAT,空闲列表和恢复日志)(黑框和箭头)。 从基线(灰色框)扩展了某些结构(例如PRF,整理缓冲区(ROB),PRF记分牌和SQ / SB),以支持OoO发行和指令完成。 当指令离开S-IQ时,分配这种结构。 前端管道的操作与基线相同。

(2)Register Renaming:假设SpecInO [2,1],图4说明了如何在S-IQ头重命名指令。为了提供更好的理解,我们在重命名方案中将新添加的功能标记为黑框和箭头。如第III-B节所述,如果指令不符合投机性发出的条件(即未准备就绪),则CASINO不会分配新的物理寄存器。 因此,建议的方案应该在读取RAT之后执行记分板读取,这可能会增加寄存器重命名的关键路径。 为了解决这个问题,我们假设寄存器重命名分两个阶段进行,其中阶段1由两个子阶段组成。 第1阶段的前半部分读取RAT中源操作数的体系结构到物理的映射(左上)。 在第一阶段的后半部分(右上)继续读取记分牌。 在阶段2,将目标操作数的新映射写入RAT。

目标操作数根据源物理寄存器的可用性进行重命名。 例如,如果I1尚未准备就绪,则将当前映射到其目标操作数的物理寄存器重新分配为目标标记(黑色MUX)。 如果I2尚未准备好,则将其重命名禁用,因为滑动偏移量设置为1;否则,I2不能重命名。 无论I1是否为推测性发布,如果I2未准备好,它都无法退出S-IQ。然后,在下一个循环中将I2重命名。 如果I1和I2都准备就绪,则会分配两个空闲的物理寄存器。 为了支持从属指令的背对背发行,将当前指令的源标签与前一组指令中的指令的目标标签(与记分板读取并行)进行比较(为简洁起见,图中未显示)。 如果匹配,并且前一条指令是具有可用源操作数的单周期操作,则当前指令将其源操作数标识为就绪

(3) Issue, Execute, and Write Back:一个周期内,从S-IQ和/或IQ发出最多两个指令。 如果准备发布两个以上的指令,则通过简单的仲裁选择目标指令,从而优先考虑IQ上的指令。 这是因为由于指令的重要性[24],最早的优先调度方案比其他方案具有更好的性能,并且来自IQ的指令总是比来自S-IQ的指令更旧。 选定的指令根据其类型发布给FU或LSU。

在执行结束时,指令根据其问题类型将结果写入不同的位置。 如果从S-IQ发出指令,则将结果值写入其目标物理寄存器。 另一方面,IQ发出的指令不得更新目标寄存器,因为IQ的多条指令可能共享该寄存器。 在这种情况下,将结果值临时写入一个小的数据缓冲区,该缓冲区的作用与基线中的SCB相似(第III-A节)。 当从IQ发出指令时分配数据缓冲区条目,并在从ROB提交相应指令时释放数据缓冲区条目。 发出其使用者时,保留在缓冲区中的值将直接转发到PRF读取阶段。 以这种方式,消除了WAW依赖性,而没有为传递给IQ的指令分配空闲的物理寄存器。

每个物理寄存器的可用性都在PRF记分板上维护,该记分板从基线开始扩展以容纳更多数量的物理寄存器。 每个PRF记分板条目都保存相应物理寄存器的状态(“就绪”位,“发布”位和“延迟”字段)[32]。发出指令时,它将复位就绪位,将发出位设置为零,并以其执行等待时间更新延迟字段。 在每个周期,设置了“发出”位的“延迟”字段将减一。 当“延迟”字段变为零时,“就绪”位被置位。 为了处理IQ中指令之间的寄存器共享,我们向每个PRF记分板条目添加一个ProducerCount字段,以指示已映射但尚未发出的指令数。 由于IQ中的指令是按程序顺序发出的,因此仅当映射到其的所有指令完成执行时,物理寄存器的最后一个实例才准备就绪。 每次将物理寄存器重新分配给转向IQ的指令时,ProducerCount都会增加,并在发出相关指令之一时减少。 如果ProducerCount变为零,则将发布位置1。 我们使用4条目数据缓冲区和2位ProducerCount,每个物理寄存器分别允许多达4条已发布(但未提交)指令和3条指令(在IQ中)。

(4)memory Disambiguation:CASINO将SQ和SB实现为单个CAM结构,其中SQ部分和SB部分使用三个指针在逻辑上进行划分:SQ尾部,SQ头与SB尾部之间的边界以及SB头[19]。 这是基线中已经存在的SB的简单扩展。 当商店离开S-IQ时,会将其调度到SQ尾部。 在提交到SQ头之后,它位于SB尾部。 最后,退出更新SB头的L1。

图5描述了如何在我们的设计中发布和重载负载。 发出装载后,将在SQ和/或SB中搜索与装载地址匹配的较旧商店。 如果存在匹配项,负载将检查是否存在比匹配的商店还年轻的未解决的商店。 如果存在此类未解决的存储,则负载将其中的最旧存储设置为前哨(即,它在ROB [19],[26]中的位置)。 如果没有匹配的存储,则会使用前哨设置最早的未解析存储。 在这两种情况下,目标商店在SQ中的位置都会写入到负载的ROB条目中。 如果商店位于SQ中并且尝试设置该哨兵的新负载比前一个年轻,则可以替换该商店的哨兵。 在提交时,负载会搜索SB(从SB尾部(即最近的商店)到设置哨兵的商店)以验证推测。 如果存在匹配项,则检测到内存顺序冲突,并且从管道中清除此类过早服务的负载和所有后续指令,然后重新执行。 否则,如果当前负载是设置哨兵的最新负载,则删除商店中的哨兵。 如果没有哨兵,则允许SB头的商店退役。

通过延迟远程存储的停用(与早于未执行的旧负载发出的负载发生冲突),直到提交推测性负载[19]来强制执行负载排序。 这消除了LQ搜索的需要,同时支持总商店订购(TSO)。 为此,以推测方式发出的负载将哨兵设置到相应的缓存行,并且该缓存行从远程存储中保留对无效的确认,直到在提交时由负载将哨兵删除为止。

提交时值检查可有效删除LQ上的关联搜索。 但是,SQ / SB上的搜索数量会增加,因为每个负载在提交时都会执行一次其他搜索以验证其推测。因此,即使SQ / SB消耗的能量比常规LSU少,它仍会成为大型的,关联的集中式结构。 为了解决这个问题,我们利用[33]中的观察结果,(i)不仅很少发生违反内存顺序的情况,(ii)而且许多存储和装载甚至都不访问相同的地址。 我们的主要见识是,要避免使用未解决的商店来避免违反订单,就需要进行预测,而使用已经解决的商店则不需要。基于(i),我们忽略了未解决的商店与当前已发布的负载之间的潜在依赖关系(性能损失可忽略不计),仅关注已解决的商店与当前已发布的负载之间的明显依赖关系。 换句话说,当确保具有解析的匹配地址的商店不驻留在SQ / SB中时,负载将跳过SQ / SB搜索。

为此,需要维护所有已发行但尚未退休(即未清)商店的地址。 但是,缓冲所有这些地址效率很低,并且还需要CAM搜索。 在这里,我们利用(ii)来建立一个能效高的存储,将信息存储在未完成的存储中,即未完成的存储计数器阵列(OSCA)(图5)。 OSCA是由内存地址的低位索引的哈希表。 每个OSCA条目都是一个饱和计数器,其中包含未完成存储的数量。 OSCA条目由已发行的存储增加,而由退休的存储减少。 发出负载后,将访问相应的计数器,如果计数器值为零,则负载将跳过SQ / SB搜索。 即使当前计数器值可能无法反映较旧但未发布的存储,但内存顺序冲突不会增加。 这是因为OSCA的作用是,在确保不存在具有相同目标地址的未完成存储时,删除负载的SQ / SB搜索。

另一个问题是别名问题,其中使用不同目标地址的操作访问相同的OSCA条目。 地址别名会导致误报,从而导致冗余SQ / SB搜索。 但是,如(ii)中指出的,匹配地址很少出现,因此不同存储之间的别名也很少出现。 为了减轻不同目标地址之间的混叠现象,我们使用启发式方法找到最佳设计点,并将OSCA配置为容纳64个计数器。 第四节讨论了其他实施问题。

(5)Commit of Instructions:CASINO使用ROB来保留程序语义,该ROB跟踪飞行指令的顺序,其中每个ROB条目ID均由Buyuktosunoglu的方法编码[26],[19]。 当指令离开S-IQ时,ROB条目按程序顺序分配,并在它们完成执行时乱序更新。 在ROB头,通过释放先前分配给其目标操作数的物理寄存器来提交指令。 注意,在我们的重命名方案中,空闲的物理寄存器仅分配给推测发出的指令。 因此,从IQ调度的指令不得释放先前映射的(当前已映射的)物理寄存器以保留精确状态。 即使ROB是多端口内存,在现代设计中它的复杂性和功耗也相对较低,因为单独的IQ和LSU消除了对ROB进行关联搜索的需要。

如果检测到任何异常或错误推测,则使用恢复日志来恢复RAT和PRF记分板并释放推测分配的物理寄存器。CASINO有条件地分配可用的物理寄存器,因此恢复日志仅需要保留一小套寄存器映射。 因此,恢复过程需要几个周期才能完成,这比使用ROB中的映射要快得多。 通过依次使IQ中的指令出队(小于违规),可以恢复ProducerCount 。 根据我们的模拟,它们通常与负责RAT恢复(即由S-IQ发出)的错误推测指令相似或更少,因此它们对关键恢复路径的影响可忽略不计。同时,比有问题的指令更早的指令被一一提交,并且推测的负载验证其推测并重置相应的标记。 如果有问题的指令是错误推测的负载,则不需要此步骤,因为它是最早的飞行指令。 最后,清除了SB中的所有标记。 在违规指令到达ROB头之前,不允许设置其他哨兵[19]。 OSCA的恢复处理方式有所不同,因为它同时包含已提交和未提交的存储。 当恢复开始时,比问题指令还年轻的存储从SQ尾部逐一出队,并且相应的计数器递减。由于CASINO使用中等大小的SQ / SB(8个条目),因此允许两个存储(每个周期)访问OSCA足以隐藏此恢复延迟。

4. 关于 CASINO CORE的讨论

在本节中,我们解决了实现CASINO核心微体系结构时出现的一些问题。

(1)Register Renaming:我们提出的重命名方案比常规方案使用更少的物理寄存器。因此,可以使用较小尺寸的RAT,PRF和PRF记分板来实现。 对于PRF记分牌,即使使用传统方案,也需要在每个周期中检查源操作数的可用性,因此端口数量和整体访问次数不会增加。

CASINO核心使用数据缓冲区临时存储从IQ发出的指令结果,即从发出到提交该指令都维护数据缓冲区条目。 这比传统方案中物理寄存器的生命周期短得多,在传统方案中,物理寄存器必须从重命名到重新定义(提交更新同一目标操作数的年轻指令)。 由于传递给IQ的指令通常属于较长的依赖链,因此从重命名到发出的间隔将很长。 寿命越短,表示有效尺寸越大,从而可以更有效地利用存储空间。

(2)Store Queue/Buffer:在我们的设计中,负载遇到以下情况之一:1)从S-IQ发出的负载首先查找OSCA。 如果相应的计数器值不为零,则在必要时搜索SQ / SB并设置标记。 2)从IQ发出,它查找OSCA并根据计数器值搜索SB部分。 在这种情况下,由于所有先前的存储都已经发出,因此负载不需要设置标记。 3)到达ROB头,它搜索SB并删除已设置的标记。 如果前哨之前的目标地址中有匹配项,则刷新管道。

我们需要对SQ / SB结构进行修改,以仅对一个部分(SQ部分或SB部分)执行搜索。 这可以通过在实际执行比较[19],[35],[36],[37]之前选择目标部分来实现。同样,我们需要最老的优先和最年轻的选择逻辑来分别找到地址匹配的最年轻商店和地址未解析的最老商店[26]。 最后,将来自选择逻辑的结果进行比较,以决定是否设置标记。 有关更多详细信息,请参见[19]。 提出的过滤机制允许某些负载跳过对SQ / SB的搜索。 在这种情况下,仅通过每个SQ条目的1位“已解析”标志来搜索未解析的商店以设置标记,以指示相应商店的地址是否已解析

(3)Outstanding Store Counter Array:为了正确地跟踪未完成的存储,当相应的OSCA条目饱和时,存储问题必须停滞。 该停顿可能会导致性能大幅下降以及死锁情况; 即使相应的计数器已由S-IQ发出的后续存储饱和,IQ头上的存储也无法提交,即使提交后也是如此。 由于此存储阻止后续的存储退出,因此相应的计数器不能永远递减。 为了解决此问题,我们将每个计数器的大小配置为log2(SQ + SB项)位,这允许计数器保存所有未完成的存储。

通过使用目标地址所在的范围对OSCA进行索引,可以处理未对齐的内存访问。 例如,在4字节范围内,具有较低位[0,1,2,3]的内存访问将访问同一OSCA条目(右移两位)。因此,可以捕获4字节范围内的未对齐访问。 如果存储数据大于4个字节或未对齐,则更新连续的OSCA条目。 类似地,负载检查连续条目中是否存在较大或未对齐的数据。 实际上,很少会发生未对齐的内存访问,因此不会损害OSCA的有效性。
由于OSCA是小型直接映射的无标签SRAM,因此可以在一个周期内对其进行访问。 因此,我们认为对OSCA和SQ / SB的两次顺序访问可以在数据高速缓存访问延迟(现代处理器中为4个或更多个周期)内进行。

5. 实验方法

在评估中,我们使用了执行驱动的周期级x86处理器模拟器Multi2Sim [38],该模拟器经过了重大修改,以实现和评估所提出的设计。通过将DDR4 DRAM仿真器Ramulator [39]与处理器仿真器集成来对存储系统进行建模。 表I中列出了评估模型的体系结构参数。为了公平地比较,我们均等地设置所有评估模型的管道宽度和调度窗口的大小。 高速缓存和内存系统也被配置为相同,因为我们主要专注于揭示各种调度技术的含义和拟议设计的潜力,同时最大程度地减少来自其他体系结构功能的干扰。 设置其他参数时要考虑性能与面积/能源开销之间的折衷。 第VI-F节介绍了对更广泛发行的机器的进一步架构探索。

我们通过运行SPEC CPU2006基准测试套件[40]中的12个SPECint和13个SPECfp应用程序来评估我们的设计。 对于每个应用程序,我们使用SimPoint方法[41]选择最有代表性的3亿条指令区域。 在3亿条指令的预热阶段之后,使用参考输入集执行仿真。 为了估计能量消耗和芯片面积开销,我们使用修改版的McPAT [42],[43]和CACTI 6.5 [44],仅考虑了核心组件,不包括二级缓存,主存储器和互连网络。 我们在22nm技术节点上对数据路径和结构进行建模。

6. 结果与分析

6.1 性能

(1)Comparison to InO and OoO:图6显示了归一化为InO核心的负载切片核心(LSC)[15],Freeway核心[16],CASINO核心和OoO核心的性能。 与InO相比,CASINO在所有应用程序中均实现了显着的性能提升(平均51%,在仙人掌ADM中最高达到89%)。 这是由于CASINO通过推测性发布任何类型的指令来利用ILP和MLP的能力。 CASINO的性能在OoO的10个百分点以内。 这种性能差异是因为OoO能够在IQ的任何位置发布指令,而CASINO仅检查S-IQ和IQ的调度窗口中的指令。 请注意,CASINO在LQ上执行指令调度而不会耗费大量的唤醒和选择操作以及相关搜索。 此外,空闲的物理寄存器仅分配给推测性发出的指令,因此所需的物理寄存器数量大大减少(此实验中使用的物理寄存器减少了36%)。 在h264ref中,CASINO 表现出比OoO更好的性能。 这是因为h264ref包含大量相互依赖的加载和存储。 因此,即使它使用内存依赖预测器[45],也经常在OoO中检测到内存顺序冲突。 另一方面,在S-IQ和/或IQ的每个头部依次检查CASINO中的内存操作。 仅当从S-IQ发出负载而目标地址(实际上)是相同的较旧存储位于IQ中时,才会发生内存顺序冲突。在我们的设计中,这种情况相对较少。

(2)Comparison to LSC and Freeway:图6还显示了无序切片(sOoO)内核的性能,这是最相关的现有工作,旨在通过扩展InO内核来实现节能MLP开发。 在这些实验中,我们使用32个条目的IQ以及不限数量的其他资源来检查sOoO内核的潜力。 LSC [15]通过使用迭代后向依存关系分析来提取以负载或存储结尾的后向指令片。被标识为属于片的指令被分派到旁路队列(B-IQ)并以程序顺序发布,但与主队列(A-IQ)的指令无关。通过尽早发出潜在的缺少缓存的负载,多个内存访问可以重叠,因此它们的延迟隐藏在第一次未命中的停顿后面。 严格按照B-IQ的顺序发布所有AGI,因此永远不会发生违反存储顺序的情况。 平均而言,通过比其他方法更早地调度存储片中的指令,LSC的性能比InO高28%。

但是,在某些情况下,当连续切片具有依赖关系时,LSC可能会失去提取MLP的机会,而从属切片会阻止较年轻的独立切片的问题。 为了解决这个限制,Freeway [16]引入了一个依赖关系感知切片调度策略。 在Freeway中,具有至少一条指令的依赖条带将依赖于较早条带的负载,并将其分配到生成队列(Y-IQ)。 因此,可以发布B-IQ中的切片,而不会由于切片间的依赖性而导致停顿。 CASINO的性能比Freeway高出17%,后者比InO达到34%的性能提升。 两个关键特征有助于CASINO的相对利益。
首先,CASINO以投机性方式发布指令,而不考虑其类型(即是否为AGI)。 因此,CASINO通过利用级联的IQ来同时利用ILP和MLP。 请注意,即使sOoO核心主要集中在对MLP的利用上,但早期发行的AGI还是受益于一定数量的ILP,这是积极的副作用。 第二个特点是,CASINO中的内存消除歧义技术允许在较旧的未解决的负载和存储之外发出准备执行的负载,这有助于提高性能。

6.2 寄存器重命名的效果

S-IQ通过将先前的未就绪指令传递给IQ,从而在停顿后找到就绪指令。 使用常规的重命名方案,如果没有可用的物理寄存器,则无法传递指令。 因此,缺少免费的物理寄存器可能会损害CASINO投机发布功能的优势。 考虑到面积和能源开销,增加PRF的尺寸并不是一种有吸引力的方法。 我们通过跳过将物理寄存器分配给传递给IQ的指令来解决此问题。 图7a显示了当我们使用[N整数,M个浮点]物理寄存器将常规(ConV)和条件(ConD)重命名方案应用于CASINO时,每个周期的性能和物理寄存器分配计数。 由于配备了32个整数寄存器和14个浮点寄存器,因此ConD在每个周期中分配的寄存器数量比ConV少27%,这有助于增加推测(Sp)和正常发行率,如图7b所示。 原因是,在S-IQ头上,可以将具有不可用源的指令传递给IQ,而无需消耗寄存器,并且可以使用传递的指令保存的寄存器来推测性地发布具有可用源的更多指令。 通过应用有条件的重命名方案,最终结果是总体发行率提高了10%,性能提高了6%。 ConV [48,24]显示出与ConD [32,14]类似的性能增益,这表明所提出的重命名方案将PRF的有效大小增加了57%。 平均而言,通过建议的重命名方案,S-IQ会发出65%的动态指令。

6.3 内存消歧的效果

图8a和图8b代表了具有各种内存消除歧义方案的CASINO的LSQ相关活动计数,性能和能效。 显示值被标准化为常规OoO内核已采用的带有16项LQ的Fully OoO的值。 当我们强制以程序顺序在S-IQ头处发布AGI(AGI排序)时,将消除LQ读(R),写(W)和关联搜索(S)。 但是,与Fully OoO相比,性能降低了11%,因为某些属于具有长延迟操作的依赖链的AGI会导致S-IQ停顿。 通过应用提交时值检(NoLQ)[19],由于消除了LQ造成的停顿,同时又无序地调度了内存操作,因此性能比Fully OoO略有提高。但是,正如第III-C4节所指出的,由于推测负载(31%)增加了关联搜索,因此SQ变得更加耗电,因此仅提高了6%的能源效率。 最后,我们用OSCA补充NoLQ,并在相应的计数器值为零时允许负载绕过SQ上的搜索。 该方案将NoLQ的SQ搜索减少了70%,从而使能源效率额外提高了5个百分点。

6.4 Area Overhead and Energy Consumption

图9a显示了InO,CASINO和OoO的核心区域,其中每个堆叠条的高度代表相对于基线的总核心区域。 我们仅考虑核心组件,不包括非核心组件(例如L2和主内存)。 我们使用CACTI [44]进行的估算表明,CASINO超过InO的总面积为5%,考虑到性能的显着提高,这是非常保守的。 CASINO的面积归一化性能(即性能/面积)分别比InO和OoO高43%和16%。

图9b显示了能耗,其中每个堆叠的条形图表示目标模型的总能耗(静态和动态能量之和)。 即使对于某些扩展或添加的结构,CASINO的显着性能改进和较低的复杂性开销也可以显着降低能耗。 CASINO的能耗比InO高22%,但比OoO低37%。 对OoO(OoO + NoLQ)应用提交时值检查可将其能耗降低8%。 尽管如此,CASINO仍然消耗少31%的能量。 如图9a和9b所示,在CASINO中执行OoO的结构(即S-IQ和LSU)占用的面积和能量要比OoO中的要少得多。

6.5 Design Space Exploration

在本节中,我们通过评估各种IQ大小和推测性问题策略的性能优势来探索CASINO核心的设计空间。

(1)IQ Size: IQ的大小决定了SpecInO可以检查和发布长等待时间指令中的指令的距离。 因此,确定最佳IQ大小是至关重要的设计选择。 另一方面,S-IQ仅缓冲等待SpecInO调度的已调度指令,因此其大小对性能的影响可忽略不计。 图10a显示了从S-IQ(S-Issue)或IQ(Issue)发出的已提交指令的细目分类,以及假设SpecInO [2,1]具有无限其他资源的情况下,各种IQ大小的性能。 随着IQ大小的增加,更多的未就绪指令可以传递给IQ,因此Issue的比例增加。 因此,随着SpecInO更加积极地查找就绪指令,性能从4项提高到12项。 但是,IQ大于12个条目时,性能会下降,因为较大的IQ不能始终保证更高的调度性能。指令一旦进入IQ,就无法调度,直到所有先前的指令发布为止,否则所有指令将从S-IQ发出。 因此,某些指令过早地失去了从S-IQ发出的机会。

(2)SpecInO Configuration:使用较大的WS(窗口大小)和SO(滑动偏移),可以在S-IQ中较早地检测到就绪指令,但是在提高实施成本(例如RAT和PRF记分板的端口)的同时,它并不总是保证高性能。 功耗。 随着WS的增加,如果S-IQ位于SpecInO窗口之内,它们可能会及早发现就绪指令。 但是,在这种情况下,较旧的未就绪指令将被传递到IQ,在那里他们等待到达IQ头,即使其中一些指令在几个周期后准备就绪。 同样,大型指令有时会限制查找就绪指令的机会,因为指令过早地离开了S-IQ,否则将通过读取当前执行的结果进行调度。 图10b说明了WS和SO对性能的影响。 注意,WS应该等于或大于SO。 否则,某些指令可能会传递给IQ,而不会被SpecInO检查。 随着WS和SO的增加,性能达到SpecInO [2,1]左右,然后下降。 根据这些结果,我们得出结论,S-IQ的最佳配置是SpecInO [2,1]。

6.6 Toward Wider Superscalar

现代InO内核通常采用2向发布宽度[46],[47]来实现,而OoO内核则根据其利用并行性的能力而采用4种或更多方式[48],[49],[50]。 在本部分中,我们进行实验以进一步探索CASINO利用ILP和MLP的能力。图11显示了流水线宽度为3和4的经过评估的机器的性能和能效(即PER,性能/能量)。随着流水线宽度的增加,ROB,IQ,LSQ和PRF的大小将增加一倍( 即在4向发行设计中增加了4倍)。 在CASINO中,在现有S-IQ和IQ之间插入一个(3向)或两个(4向)8项S-IQ。 可以在任何IQ的开头发布准备好的说明。 S-IQ和IQ均配置有SpecInO [2,1]。 在这些实验中,条件寄存器重命名被禁用,因为在第一个S-IQ的开头被重命名后,可以从其中一个中间S-IQ发出指令。

配置为2向发行宽度的CASINO的能源效率分别比InO和OoO高25%和42%。 这是由于即使在InO中添加或扩展了某些结构,也以较低的复杂性开销实现了显着的性能改进。 而且,CASINO中用于OoO调度的结构(即S-IQ和LSU)消耗的能量比OoO中的要少得多。随着发行宽度的增加,CASINO和OoO的性能显着提高,这主要是由于它们从大量的飞行指令中进行OoO调度的能力所致。但是,由于重命名逻辑和LSU的复杂性迅速增长,CASINO和OoO的能源效率下降。 通过4向问题配置,CASINO的能源效率是OoO的2.0倍(比InO低18%),而性能却是OoO的13个百分点(比InO高68%)。 考虑到InO的性能有限和OoO的低能效,CASINO可能是实现高性能和高能效的有吸引力的替代方案。

7. 相关工作

(1)MLP Extraction:现代高性能超标量处理器使用动态调度,该调度基于其源操作数的可用性在独立指令之间生成OoO发布调度。 在大多数情况下,不可用的源操作数直接或间接取决于缺少缓存的负载,因此,利用MLP在实现高性能方面起着至关重要的作用。 先前的大量工作都集中于在OoO核心上提取MLP,例如预取,先行执行[51],[52]和推测性预执行[53],[54],[55]。这些技术成功地隐藏了较长的存储器等待时间,但是由于底层的OoO管线和附加的软件和/或硬件支持的复杂性,因此不适合于能量受限的环境(例如,移动的)。为了解决这个问题,另一项工作提出了基于切片的MLP开发技术,该技术建立在节能的In-on使用时失速内核中[15],[16]。 但是,依赖链的各种形状和大小可能会限制其利用ILP的能力[16],[17]。

(2)Energy-Efficient Dynamic Scheduling: 为了减少动态调度的功耗,研究人员提出将混合调度的概念引入OoO管道。 这些工作背后的关键见解是,指令属于单个依赖链(或分片[14]),无法并行执行,因此,此类指令无需通过复杂的唤醒和选择逻辑进行调度。 在[5],[56]中,依赖于长等待时间操作的指令被暂时保存在一个小的缓冲区中,直到它们的依赖关系得到解决。 稍后,将此类指令推回IQ,并以最少的唤醒和选择操作进行调度。 [7],[8]根据源操作数的可用性和相关性,将无法从OoO调度中受益的指令转移到InO IQ。 文献[7]中的单独的InO IQ减少了因依赖链混杂而造成的停顿。 但是,它们的性能仍然高度依赖于依赖链的形状[17]。

另一种方法是使用InO执行引擎来过滤准备执行的指令。 “跳动闪烁”两遍流水线[57]使用两个顺序的InO后端来隐藏高速缓存未命中的停顿。 Ready-at-patch指令在高级管线中执行,而其他指令则推迟到备用管线中。 FXA [6]在OoO后端的前面采用了由FU和旁路网络组成的InO执行单元(IXU),以节能的方式执行准备就绪的指令。 CASINO使用单个InO执行引擎采用更细粒度的方法,并实现了相同的目标,而对其他共享资源进行了少量修改。 因此,不需要执行资源和/或OoO调度逻辑的重复。

受指令轨迹[58],[59]及其发布时间表[9]的重复行为的启发,已经提出了基于重放的指令调度技术,以实现具有高能效的近OO性能[10],[11],[12] ],[13]。 关键思想是存储由OoO执行引擎生成的指令调度顺序。 在未来的迭代中,节能的InO管道将以记忆顺序执行指令流。这样的指令还有一些机会绕过几个流水线阶段(例如,获取和解码阶段)[13]。 但是,在我们提出的设计中,指令调度仅由InO管道确定,而没有OoO管道的帮助。 因此,我们的设计大大降低了实现成本和硬件复杂性。

而且,由于先前的工作以较粗的粒度(作为多个基本块的单位)调度动态指令,因此它们从意外事件(例如,高速缓存未命中,错误推测和异常)中的恢复损失比CASINO的影响更大。 从性能角度来看,这些恢复损失是不可忽略的[9]。

(3)Memory Disambiguation:已经提出了几种内存消除歧义的技术,以提高负载推测的准确性[60],[61],[62],[63],[64],[65]或减少耗电的关联搜索的数量 LSQ [33],[66],[67]。 另一种方法是消除LQ或SQ以及对这些结构的关联搜索[19],[68],[69]。 我们采用后一种方法,因为可以通过扩展基线InO核心中的现有SB轻松实现该方法。此外,基于观察到很少发生内存顺序冲突[33],[66],我们通过使用一个小的计数器阵列来减轻集中式SQ的压力。

(4)PRF Management:为了减轻对PRF的压力,研究人员提出了各种寄存器重命名方案,可以将其大致分为两类:1)延迟物理寄存器的分配,从重命名到写回[70],[71],以及2)释放短 生存的寄存器,只要将其值提取给所有使用者[34],[72],[73],[74],[75],[76]。 最近,[77],[78]通过将物理寄存器共享用于仅消耗一次的寄存器,进一步向前迈进了一步。 对于其使用者,将这样的寄存器重新分配为目标寄存器。 为了相同的目的,CASINO执行另一种类型的寄存器重命名; 跳过按程序顺序调度的指令的寄存器分配,因此IQ中的多个指令自然共享一个物理寄存器,而不会降低性能。
另外,提议的重命名方案对于能量受限的环境是有吸引力的方法,因为它既不需要预测机制也不需要检查点PRF [74],[75],[76],[77]。

8. 总结

通过利用关键见解,即通过用推测性问题的能力补充常规的InO设计,可以实现OoO调度的性能优势,本文提出了一种CASINO核心微体系结构。CASINO核心通过使用级联的InO IQ来动态和推测性地创建OoO调度,从而以接近InO的复杂性实现OoO调度。 所提出的重命名方案仅使用几个物理寄存器就可以有效地消除错误的依赖性。 我们还提出了一种内存消除歧义技术,该技术通过在基线中扩展SB来实现。 我们的评估表明,超过一半的动态指令是从SIQ发出的,与基准InO内核相比,性能得到了显着改善,在某些情况下,这可与激进的OoO设计相媲美。 全面的设计空间探索使我们得出结论,CASINO内核是高性能OoO内核的理想选择。

致谢:

这项工作得到了三星电子三星研究资助中心的支持,项目编号为SRFC-IT1801-04。 W. W. Ro是通讯作者。

二、我的阅读过程

1. 微架构的解释

参考:机器语言 | 汇编语言 | 指令集架构 |微架构 | 微处理器

前言:当我看到论文题目的时候,尴尬的事情发生了。论文的题目是,‘CASINO Core Microarchitecture: Generating Out-of-Order Schedules Using Cascaded In-Order Scheduling Windows’。Microarchitecture是什么意思呐?微架构这个词听了很多遍,但是一直没有留意它的含义。今天,我们来一探究竟。

wiki是个很好的查找名词解释的地方。当看完上面的参考文章之后,我们会明白类似于这样的问题:机器语言和汇编语言的关系?机器语言和指令集的关系?指令集与微架构的关系?指令集与微处理器的关系?微架构与微处理器的关系?而下面的文字摘录自上面的链接。下面的文字将机器语言、汇编语言、指令集、复杂指令集、精简指令集、微架构、流水线、(微)处理器之间的关系串起来讲了一遍。

ps:没有图,都是字,还都是概念,人言否?所以最后我加了几个花里胡哨的图

我们先理理可能已经清楚的知识点。什么是汇编语言?。我想看到这篇文章的人,都知道或者用过汇编。[我当年是在三个一工程学习汇编,后来退出了,感谢当年的学长。对于我个人而言,王爽老师的《汇编语言》是挺不错的书籍。人上年纪了,开始喜欢回忆

使用级联有序调度窗口生成无序调度相关推荐

  1. 【Linux 内核】CFS 调度器 ① ( CFS 完全公平调度器概念 | CFS 调度器虚拟时钟 Virtual Runtime 概念 | 四种进程优先级 | 五种调度类 )

    文章目录 一.CFS 调度器概念 ( 完全公平调度器 ) 二.CFS 调度器虚拟时钟概念 ( Virtual Runtime ) 三.进程优先级 ( 调度优先级 | 静态优先级 | 正常优先级 | 实 ...

  2. 【Linux 内核】调度器 ① ( 调度器概念 | 调度器目的 | 调度器主要工作 | 调度器位置 | 进程优先级 | 抢占式调度器 | Linux 进程状态 | Linux 内核进程状态 )

    文章目录 一.调度器 0.调度器概念 1.调度器目的 2.调度器主要工作 3.调度器位置 4.进程优先级 5.抢占式调度器 二.Linux 内核进程状态 API 简介 三.Linux 进程状态 一.调 ...

  3. Yarn调度器和调度算法(FIFO、容量调度器 与 公平调度器)

    目录 Yarn调度器和调度算法 一.先进先出调度器(FIFO) 二.容量调度器(Capacity Scheduler) 1. 容量调度器特点 2. 容量调度器资源分配算法 三.公平调度器(Fair S ...

  4. 有序列表ol与无序列表ul用法

    有序列表<ol>与无序列表ul用法 其中<li> 标签定义列表项目,<li> 标签可用在有序列表 (<ol>) 和无序列表 (<ul>) 中 ...

  5. MyBatis实现级联查询及逆向生成

    MyBatis实现级联查询及逆向生成 一,级联查询 1.级联查询 N-1 ​ 以多的一方为主表 接口 //级联查询 N-1List<Emp> selectEmp(Map map); 映射文 ...

  6. 操作系统-处理机调度详解(调度层次及FCFS、SPF、RR等算法)

    目录 调度层次 处理机调度算法 评价指标 非剥夺式/抢占式 非抢占式优先级调度算法 先来先服务(FCFS) 短进程优先(SPF) 响应比优先算法(HRRN) 剥夺式/抢占式 最短剩余时间优先(SRTN ...

  7. Linux调度器及CFS调度器

    Linux调度器及CFS调度器 调度器 调度器类sched_class结构体 进程的优先级 调度策略 CFS调度器 实际运行时间 虚拟运行时间 调度器结构分析 调度器 ​ 调度:就算按照某种调度的算法 ...

  8. 【微电网优化】基于matlab粒子群算法求解微网经济调度和环境友好调度优化问题【含Matlab源码 2283期】

    ⛄一.获取代码方式 获取代码方式1: 完整代码已上传我的资源:[微电网优化]基于matlab粒子群算法求解微网经济调度和环境友好调度优化问题[含Matlab源码 2283期] 点击上面蓝色字体,直接付 ...

  9. 指挥调度中心如何选择调度台?

    一.本质 1.1 C/S调度台软件配套要求 图1 - 华脉智联C/S调度台 说明:若客户不选择2-6的专业调度台,可以建议客户采购如下配置的台式机或一体机作为指挥中心调度台. 操作系统:WIN7/WI ...

最新文章

  1. 从底层吃透java内存模型(JMM)、volatile、CAS
  2. 企业项目学习准备阶段——Rhel6.5版本无图形虚拟机封装过程及相关配置
  3. 什么是Attention机制以及Pytorch如何使用
  4. 【计算机网络】数据链路层 : 概述 ( 基本概念 | 功能 | 为 “网络层“ 提供的服务 )
  5. [原创]SpotLight性能监控工具使用介绍
  6. Zookeeper的数据模型
  7. 科大星云诗社动态20210817
  8. 嵌入式Linux系统编程学习之三十三网络相关概念
  9. web报表工具FineReport最经常用到部分函数详解
  10. android 首页接口设计方案,Android开发最佳实践——1.接口设计
  11. [WebApp开发]基础教程-Web App开发入门
  12. OO第三单元总结——JML
  13. WIFI篇(1.windows下的CMD命令)
  14. C# 简单的ZEBRA标签打印程序
  15. 最新上市公司商誉减值损失数据
  16. 计算机报名503,503错误,教您网页出现503错误怎么解决
  17. 关于认知升级的思考-认知升级是深度思考、认知升级是探索未知
  18. 详解word2vec
  19. 你可能不需要担心,AI对你的工作造成威胁:万字长文解读科技革命与人类发展
  20. 整理项目管理工具,管理笔记,常用文档管理系统

热门文章

  1. 新概念2 课文和单词(16)
  2. 系统环境变量和用户环境变量的区别
  3. easyUI datagrid 单元格数据的修改,保存,json 数据的转化
  4. 中移在线携手华为联合打造云客服全栈自主创新样板点,输出客服能力,服务千行百业...
  5. 【LeNet-5】手写数字识别MNIST
  6. 自己给自己出本书吧……
  7. python tokenizer_中文分词工具 MiNLP-Tokenizer
  8. 【数学建模】2016年B题
  9. steamvr自定义按键_SteamVR脚本解析
  10. 【前端备份】20个国外非常漂亮的404错误提示网页模板