前阵子连续聊了好几个AI芯片项目发现一个挺明显的趋势以前只有CPU设计组才碰的Out-of-Order乱序执行套路现在在NPU和GPGPU的架构讨论里出现得越来越频繁。有人觉得这太正常了CPU那套成熟方案直接平移过来就行也有人觉得乱序执行面积昂贵、功耗高在AI这种规则计算场景里纯属浪费。我自己的看法是这两种说法都只说对了一半。乱序不是银弹但它也不是CPU专属的老古董真正要做的是把“乱序”这个词放进NPU/GPGPU的真实痛点里重新理解一遍。所以这篇文章我打算从实际项目出发聊聊我理解的Out-of-Order NPU/GPGPU设计思路。我会解释为什么需要乱序、哪些CPU经验可以借鉴、哪些必须丢掉、以及真正落地时要怎么选参数、怎么排查问题。不管你是做架构设计的、写RTL的还是搞编译器对接的只要能跟着过一遍应该能少踩不少坑。1. 为什么NPU/GPGPU会开始认真考虑乱序执行1.1 CPU乱序那套东西为什么不能无脑搬过来先说清楚CPU里的乱序执行到底在干什么。乱序执行的本质是程序写出来的指令顺序叫“程序顺序”但硬件为了让流水线不白等会在不影响最终结果的前提下把后面的指令提前执行。为了做到这一点指令集架构里那些逻辑寄存器会被“重命名”到更多的物理寄存器上避免所谓WAR写后读和WAW写后写冒险调度器再从一大堆已经译码、已经确认依赖关系的指令里挑出能执行的那几条发射到运算单元去跑。最后还用一个重排序缓冲ROBReorder Buffer来记录指令的原始顺序保证异常能精确报告保证提交commit还是按顺序的。这套机制在CPU二维世界里确实很有效因为一个核心往往只有几条指令宽度逻辑寄存器数量也不多寄存器重命名带来的面积成本还在可控范围内。但CPU乱序有一个隐含前提指令宽度小、每周期能处理的事务量有限所以调度器可以集中式地维护一个几十项甚至上百项目的窗口。放到NPU和GPGPU上情况就完全不一样了。一条向量指令可能要同时操作几百个数据一条张量指令可能对应整个矩阵运算如果为每条指令都维护完整的物理寄存器重命名、为每个lane都保留一份寄存器的重命名映射面积和功耗会爆炸。所以我一直觉得直接照搬CPU乱序后端是条死路。真正有价值的思路是分析NPU/GPGPU在什么地方“等待”最严重然后把乱序用在刀刃上。1.2 NPU/GPGPU的真正瓶颈是存储墙不是分支预测CPU乱序要解决的核心问题很多缓存未命中、分支预测失败、访存延迟、长延迟浮点运算等等。但在AI芯片里计算模式高度规则绝大多数代码都是循环、矩阵乘、卷积、归一化这一类分支预测的负担其实远没有CPU那么重。如果你去剖一个NPU/GPGPU项目的性能瓶颈大概率都会看到同一个东西访存。这个现象在架构圈有个直白的词叫“存储墙”。以最常见的GEMM算子为例你要从DRAM或者HBM读入A矩阵、B矩阵中间计算单元可能很快就算完了但数据没到位你只能干等。HBM的访问延迟可能在几百个周期片上SRAM的容量又有限放不下大的中间结果。如果一条load指令没回来就卡住整个流水线那意味着后面的几百个周期里所有乘法器完全是空转的。有一种做法是“多线程隐藏延迟”这也是很多GPGPU的传统方案。同一个时钟周期里调度器可以频繁切换不同的warpA warp在等数据的时候B warp冲上去算。但这里面有个代价想要隐藏足够深的延迟你得有足够多的活跃线程每个线程又携带自己的寄存器状态寄存器文件被撑得特别大。而且随着算子越来越复杂比如Attention里的长序列访存单纯靠堆线程已经不够灵活。这个时候乱序执行的优势就出来了它并不要求你物理上放着几百个线程而是允许同一个线程流内的多条独立访存指令同时“在飞”把内存级并行度MLPMemory Level Parallelism拉高。1.3 乱序在NPU/GPGPU里到底解决什么问题把目标缩到“访存延迟、同步延迟、资源空闲”这三件事上就能回答这个问题了。第一个作用是隐藏访存延迟。顺序执行时load miss往往要阻塞后续所有指令而乱序可以让多条不相关的load/store提前准备好数据回来再唤醒真正等着那条数据去计算的指令。简单说每个内存级并行单位都在“替”计算单元争取时间。第二个作用是降低同步等待。AI芯片里常常有多个计算核、DMA引擎、卷积引擎并行跑一个算子算完要等另一个拿结果或者执行barrier保证所有线程都到达某个点。顺序体系下同步指令一上来整条流水线都得停。乱序执行如果配合“同步点不越过、同步之前的访存可以提前完成”这类策略就能把同步空窗期压缩。第三个作用是提升多级流水的利用率。NPU里往往不只是PE阵列还有DMA、向量单元、标量单元混在一起。指令乱序 异步派发可以让DMA搬运、计算、写回这几件事重叠起来而不是死板地“搬完一块算一块”。但要泼一盆冷水这类收益不是免费的。乱序执行本身需要更大的指令窗口、更多的寄存器文件、更复杂的调度器也会让时序收敛变难。所以设计前必须先量化确定你的系统里访存stall到底占了多少周期同步stall又占了多少然后才决定要不要上乱序、上到什么程度。2. 核心细节解析把乱序改造成适合并行引擎的样子2.1 不变量物理寄存器重命名与WAR/WAW消除既然要乱序寄存器重命名是绕不开的。先说一个最基础的原理。在顺序执行中如果第1条指令写R3第2条指令读R3这是真依赖RAW必须等如果第2条指令也写R3那么它和第1条之间就是输出依赖WAW顺序状态机里很容易处理但乱序后必须先判断谁是最后一个写的如果第1条读R3第2条写R3这是反依赖WAR乱序后第2条先写会破坏掉第1条要读的值。CPU的解法是给每个逻辑寄存器准备多个物理寄存器再用一张映射表记录“当前哪个物理寄存器代表这个逻辑寄存器”。每条需要写寄存器的指令在发射前就提前领走一个新的物理寄存器这样不同指令写同一个逻辑寄存器就变成了写不同的物理寄存器WAR和WAW冒险天然被消除。读操作则通过映射表找到最新的那个物理寄存器号。到了NPU/GPGPU上寄存器已经不是32位标量而是可能非常宽的向量寄存器甚至张量寄存器。如果不管哪条指令全都做物理寄存器重命名寄存器文件面积会大得离谱。常见的折中方案是只对“长延迟”的访存指令和“跨指令依赖必须做重命名”的指令做重命名其他纯计算指令可以沿用物理寄存器堆中的固定槽位或者采用一种RAID-like的轮转寄存器文件机制。轮转寄存器register rotation是一种在过去VLIW和部分GPGPU研究里出现过的思路。它把物理寄存器组织成环形缓冲区逻辑寄存器的编号是环上的相对位置。循环体每迭代一次整个环“转”一次硬件不需要复制寄存器内容只需要把基准指针偏移一下。这对AI里大量循环展开的场景非常友好因为循环迭代之间天然没有WAR/WAW用轮转寄存区比几十个物理寄存器端口灵活得多。另外要提醒的是NPU/GPGPU里普遍有谓词predicate寄存器用来控制向量lane的启停。重命名时不能只重命名数据寄存器谓词寄存器也要纳入管理。否则两条指令同时写同一个谓词寄存器乱序后可能会把后续向量操作的激活状态搞错。这个细节在实际验证中非常容易漏。2.2 调度器集中式还是分布式窗口放哪调度器是整个乱序执行引擎的心脏。CPU里的经典做法是统一保留站指令译码后全部进入一个大池子调度器每周期扫描所有满足条件的指令选择最老的几条发射。好处是窗口内所有指令可见坏处是复杂度随发射宽度和窗口大小急剧上升时钟频率很难做高。在NPU/GPGPU里我更推荐分布式调度。原因很简单一个芯片上基本都有多个计算簇Compute Cluster/SM/Tile如果做一个全局统一调度器意味着取指、译码、重命名、发射都要汇聚到同一个点线程同步握手就会变得极其昂贵。分布式思路是每个计算簇内部负责自己的指令窗口簇内再分成“访存调度”和“计算调度”两个队列。访存指令进了访存队列后它是乱序发射的计算指令要等它依赖的访存数据回来被唤醒才发射。数据回到某个物理寄存器后调度器会检查有哪些指令依赖这个寄存器然后送入发射阶段。发射宽度在这个场景里也要重新考虑。CPU往往追求每周期发射4-8条微操作但对NPU/GPGPU来说一条向量指令就已经相当于CPU几十条甚至上百条微操作的运算量。我见过不少项目一开始照着CPU习惯做四发射、双发射结果面积暴涨性能却上不来。真正靠谱的做法往往是“单发射、但发射一股很大很宽的指令”并且把调度重点放在访存指令的提前发起上而不是让计算单元同时塞进一条又一条向量指令。窗口放在哪里也值得斟酌。如果指令窗口放在取指之后、译码之前那你看到的是“未来指令”可以更早发现访存机会但可能会把分支指令、跳转指令的约束搞得非常复杂。放到译码之后每条指令已经确定操作数依赖调度器能更精准判断哪条访存指令没有依赖可以提前发射。绝大多数NPU/GPGPU乱序设计采用后者先译码再进入乱序窗口。甚至有些设计的窗口不是传统ROB而是“两段式队列”一段专门放还没解析地址的访存指令一段放等待唤醒的计算指令。2.3 存储访问与同步指令的乱序边界乱序执行最敏感的地方永远在访存和同步。访存指令一旦乱序不同地址之间的读写依赖需要硬件检查否则一个load可能踩到别人刚store的内存或者一个store覆盖了别人还没load的值。在CPU里Load/Store Queue承担这个检查任务它会记录每条访存指令的地址和状态并强制地址冲突的指令恢复顺序。NPU/GPGPU的访存队列设计得更复杂因为访存指令的操作数往往是向量地址一条指令能覆盖一整段连续内存所以队列既要检查地址范围有没有重叠又要维护多个处理器的缓存一致性。做设计的时候我建议优先把“同地址重叠”检查做得精简只需要判断区间是否相交不用做到CPU那种按cache line逐字节翻查的精细度。AI计算的访存模式高度规整绝大多数冲突是整块区间冲突区间的粗粒度检查已经能扛住大部分case。还有一个特别容易被忽视的点同步原语。NPU/GPGPU里的barrier、fence、atomic操作本质上是在定义“谁必须等谁”。乱序执行如果让某条barrier指令越过前面的load/store就破坏了同步语义。所以设计中一定要明确同步指令是整个乱序窗口里的“硬边界”。它可以不卡住所有计算但它在逻辑上必须等到前面所有被它约束的访存操作完成并且它自己不能被后面的普通访存指令越过。实现上最简单的方式有两种一种是给同步指令一个特殊token只有前面的所有访存都提交后token才释放另一种是单独开一条“同步流水线”同步指令不走普通访存队列走专用通道直接在提交阶段执行。我踩过的坑是一开始为了简化硬件把barrier当成普通store来处理结果两个warp互相等待barrier还没真正落地后面的load已经读到旧数据整个kernel结果全错。这种问题排查起来极其耗时间因为功能仿真有时候根本跑不出时序问题必须做带延迟注入的模型才能复现。3. 实操过程从架构参数到验证环境怎么落地3.1 一个可参考的框架与流水线流程聊完理论给一个我习惯用的中等规模NPU/GPGPU乱序设计框架做参考。假设芯片有16个计算簇Tile每个簇内有32个lane簇内支持最多1024个线程每个线程有自己的向量寄存器上下文。整体流水线阶段可以划为取指Fetch→ 译码Decode→ 重命名Rename→ 调度Schedule→ 发射Issue→ 执行Execute→ 写回Writeback→ 提交Commit这和CPU流水线看起来像但内部实现有不少差异。取指阶段要支持多warp的指令缓冲也就是说同时从多个warp取指令而不是单一PC译码阶段会把向量/张量指令拆成“访存部分”和“计算部分”的依赖关系但不会真拆成两条微指令而是记录成两个队列之间的连接关系。重命名阶段这里要做的事情比CPU少因为AI指令大量是向量运算很多warp内的lane共享寄存器映射所以重命名粒度可以做到“每warp一组寄存器号”而不是“每lane一个物理寄存器号”。调度阶段分两条线访存指令进入Load/Store Queue计算指令进入一个小的Wakeup/Select矩阵。Rename完的指令如果依赖还没就绪就会被挂在等待状态数据写回时会通过广播方式唤醒等它的指令。提交阶段在GPGPU里压力也不小。每个周期能提交几条指令、每条指令要不要更新PC、异常怎么处理都会影响整体吞吐。但好消息是AI负载对精确异常要求不那么高很多NPU甚至可以直接做到“不打断整块任务出错就报error由软件重跑整个kernel”这大大降低ROB复杂度。于是很多设计的ROB会被简化成一条条的完成位而不是CPU那种精确PC恢复机制。3.2 关键参数估算窗口深度、物理寄存器数、访存队列参数设计不能拍脑袋我习惯先用一个简单模型估算。核心目标是在目标访存延迟L个周期、平均发射吞吐为每周期I条指令的情况下至少需要多少条不相关指令“在飞”才能让流水线不被访存卡住。粗略公式如下需要隐藏延迟的最小并发数 L × I假设访存延迟是300周期目标平均每周期发射1条向量指令那你至少要有300条指令已经发射出去并且处于等待数据或者运行中状态。如果每条指令里平均有2个独立访存请求那么内存级并行需求就是600个并发访存。这个并发数会直接换算成指令窗口大小、物理寄存器数量、访存队列深度。给一个我自己常用的参数估算表格具体数值按16个簇、每个簇目标1GHz、访存延迟300周期、平均每秒跑1条混合向量/访存指令来估参数估算依据参考范围乱序窗口深度每簇需要隐藏的并发指令数 × 流水线级数 / 发射宽度64~256物理寄存器数每簇窗口深度 × 每条指令写物理寄存器的最大值 当前活跃上下文2048~8192Load/Store Queue深度同时存活的访存指令数 同步原语预留项32~128同步指令队列深度每簇内活跃的barrier/fence数目8~32每周期发射宽度硬件复杂度与时钟目标折中1~2这里要特别解释一下为什么窗口深度不是直接等于L×I。因为不是每条指令都会在窗口里待满L个周期有的计算指令很快就能执行完另外还有warp切换、任务级并行在帮你隐藏延迟。所以我算出来的300个并发数会被进一步折减到64~256。折减的幅度取决于负载里访存指令占比到底多高以及不同warp之间访存是否能真正重叠。如果占比很低窗口取128已经足够取太大纯属浪费寄存器。物理寄存器数则和指令写寄存器数量密切相关。向量指令写一个向量寄存器可能对应32个lane每个lane要有一个物理寄存器槽。假设窗口深度256每条指令最多写2个物理寄存器那么理想情况需要512个物理寄存器槽但因为要处理重命名后的临时变量、warp上下文的保存恢复实际往往要留1.5~2倍裕量所以范围放到2048以上并不夸张。访存队列深度我觉得宁可多不要少。因为访存指令一旦发射出去它的地址和状态就占用一个LSQ条目直到数据返回并写回。如果LSQ满了后面所有访存都得堵住乱序窗口再大也被憋死。常规经验是LSQ深度至少是窗口深度的一半同时为每个warp预留至少2~4个条目给同步原语。3.3 让软件与编译器配合乱序乱序硬件不是万能的软件和编译器如果不配合效果会大打折扣。最典型的问题是指令集层面没有表达“依赖关系”的手段。编译器如果把所有指令都标记成相互依赖那硬件再大的窗口也没用每周期只能在依赖链上慢慢爬。所以现代NPU/GPGPU指令集往往会引入显式的event/token机制。也就是一条指令可以“等某个事件计数器归零”再真正执行另一条指令可以“算完之后把某事件计数器减一”。编译器负责把跨block、跨指令流的依赖关系转换成一连串wait_event和signal_event。这样硬件乱序窗口看到的是更细粒度的依赖关系而不是一个笼统的barrier。编译器在做指令调度时也要注意一个原则尽量把访存指令提前。比如GEMM循环体里先算好下一轮A矩阵的地址尽早发load再算当前这一轮的乘加。虽然硬件能乱序但编译器如果把load排在很后面硬件窗口再深也只能等到译码之后才发现这条访存指令白白浪费了取指到译码那一段周期。另外不要滥用fence指令。很多程序员为了保证正确性会在每个循环里插fence。当硬件已经做了访存依赖检查后fence大多数是不必要的。fence插得越多乱序窗口越难开性能回落得越明显。还有一个容易被忽略的配合点动态形状。AI负载经常有输入尺寸不固定循环次数可能是运行时的值。编译器如果不知道一次循环要跑多久硬件的分支处理就会变保守。建议在指令集里支持“可断言的循环结束”通过谓词让循环体最后几次迭代不需要单独处理边界分支给乱序调度器省下不少分支误判矫正的开销。3.4 用事件驱动模拟器做早期验证乱序设计的验证不能等到RTL写完了再来我强烈建议先用事件驱动模拟器把整个微架构模型搭出来。这一步看起来多花了时间实际上能帮你省掉后面好几个月的返工。我自己常用C写一个轻量的周期近似模拟器模块上对应ROB、物理寄存器、访存队列、同步队列、各计算单元延迟模型。它不追求和RTL完全周期级一致但要求能准确反映“指令在哪一个阶段等了多少周期”。负载就用最典型的GEMM、Elementwise、Attention做benchmark。测的时候一定要注入随机延迟把HBM访问延迟设置成带抖动的分布而不是固定300周期否则很多边界问题在模拟阶段根本发现不了。模拟器里我最关注三个数发射队列空置率、访存队列满占用率、同步等待周期占比。如果发射队列空置率很高说明没有足够的可执行指令窗口太小或者依赖太重如果访存队列长期接近满说明内存级并行要求太高要么窗口需要控制要么bandwidth不够如果同步等待周期占比超过20%就要回头检查是不是barrier粒度太粗。早期模型验证还有个意想不到的好处它可以给编译器团队提供一个量化的“并行度目标”。比如某个算子理论上需要达到多少并行度才能跑满硬件编译器看到这个数字后就能决定怎么展开循环、怎么插event事件。这点在软硬件协同优化里特别重要不然两边各自埋头做最后系统合在一起性能对不上你们互相甩锅的时间可能比写代码还多。4. 常见问题与排查技巧实录4.1 乱序之后性能不升反降这是几乎所有团队都会遇到的第一道坎。模拟器显示乱序设计能提升20%结果真正跑起来比顺序版还慢。原因往往不是一个而是好几个叠在一起。最常见的是寄存器重命名开销太大。当物理寄存器端口成为瓶颈时每周期连发射一条指令都困难乱序窗口里的指令再多也发射不出去。这时候你会看到性能报告里“发射队列满”周期占比特别高。另一个典型原因是调度器延迟占用了关键路径。有些团队为了追求大窗口把调度器的Wakeup/Select矩阵做得很大组合逻辑长到时钟频率掉了20%。算下来窗口大了频率低了性能收益全部被抹掉。遇到这种情况我通常建议先把发射宽度降到1窗口缩小到原来的一半然后把时钟频率做上去。很多时候性能反而更好因为AI负载里真正依赖大窗口的场景没有想象中那么多。还有一个系统级原因是访存带宽已经饱和。乱序把访存指令提前系统里bank冲突、MSHR未命中率可能同步升高。看起来load被提前发起了但大家都挤在内存控制器门口排队平均延迟不减反增。这时候性能不升反降其实不是乱序的问题而是内存子系统没跟上需要降低MLP或者优化地址交错。4.2 死锁问题barrier、同步原语与乱序执行打架乱序执行引入最大的风险之一就是死锁。一个经典场景是这样的warp0在barrier处等待warp1到达但warp1在到达barrier之前需要读warp0写出的一个数据而warp0之所以没写出这个数据是因为它自己在等barrier释放。如果硬件允许barrier指令被拖到访存队列之后乱序完成这个环形等待就可能被触发。排查死锁时硬件里最好有一个“同步等待状态寄存器”能显示每个warp当前在等什么同步原语、等了多久。按我的经验死锁复现概率不一定高要靠随机延迟注入来逼它现形。一旦复现先看所有的barrier是否都严格遵守“不能被越过的边界”这一条再看是否有两个以上的同步事件互相等待对方释放资源。修复上有一个实用技巧给同步事件加“序号”。每个事件都带一个不断递增的tag只有当前面的地址访问完成且事件tag满足依赖后同步指令才允许提交。这个tag机制实现起来不复杂但能让硬件和验证环境都能精确定位是哪一对依赖导致死锁。另一个技巧是“超时看门狗”同步等待超过一定周期后直接抛异常并dump现场。真实硅片调试时这个机制救过我很多次否则卡死一次就要重新跑整个仿真成本太高。4.3 访存拥塞与局部性劣化乱序执行会让访存请求更早涌入内存系统如果设计不对局部性会被冲散。顺序执行时同一cacheline的访问往往挨在一起能合并成一次memory request乱序后提前发射的load可能来自不同cacheline打散了合并的机会导致内存事务数量增加带宽效率变差。解决思路是不要什么访存指令都一窝蜂乱序而是给访存发射加“合并优先”策略。调度器在准备发射load/store时先去检查访存队列里有没有地址相近的请求如果有就让它们尽量靠在一起做合并如果完全无关才考虑提前发射。另一种做法是把访存指令分组连续地址的向量访存天然是一个内存事务把它当成一个整体跨步很大的指针追逐型访问则严格等待地址解析。观察这个问题的性能计数器主要是MSHR占用率和内存控制器bank利用率。如果MSHR长期接近最大值说明有太多独立miss在飞。我通常会限制每个warp最多同时有4~8个未完成miss超过就不要再提前发射新的访存指令。这样虽然理论MLP降了一点但内存效率会大幅提升总吞吐反而更好。4.4 调试手段性能计数器 波形反推乱序设计的调试比顺序设计难一个数量级因为指令执行顺序随时在变。你很难像顺序流水线那样说“这条指令在第几个周期执行”它可能提前执行了也可能等了几百个周期。所以必须把“性能计数器”和“波形反推”结合起来用。性能计数器至少要覆盖这几类信号计数器事件含义调优方向issue_slots_empty发射槽为空提高窗口/指令级并行load_queue_full访存队列满增大LSQ或限制访存发射register_file_ports_conflict寄存器端口冲突增加端口或降低发射宽度sync_wait_cycles同步等待周期优化barrier粒度/编译器插入msrh_occupancyMSHR占用限制MLP优化局部性commit_width_avg平均每周期提交数检查后端瓶颈拿到这些计数器之后再翻波形。我会习惯在仿真器里给每个warp打一个“事件时间线”记录它从取指到提交的每一个关键节点进了调度窗口、被唤醒、发射、数据返回、提交。一旦性能有问题先把时间线拉出来找那个空档特别大的warp看看它卡在哪个阶段。如果大量时间卡在“唤醒后等发射”那是调度器或寄存器端口的问题如果卡在“数据返回前”那是访存延迟或MLP不够的问题如果卡在“同步等待”那是上游任务没算完需要编译器去调同步位置。另外如果条件允许建议对同步语义和访存一致性做形式化验证。这类问题靠仿真去“试”很痛苦因为组合空间太大。用属性检查把“barrier不能越过前面的global write”这类约束写成断言让验证工具去穷举。等这条断言确认通过后你再去调试性能问题会轻松很多。5. 最后想说的话说句实话乱序执行在NPU/GPGPU上并不是一个“有或没有”的问题而是一个“在哪一级、什么粒度、为了什么”的问题。我见过有些团队一上来就要做巨大乱序窗口结果面积爆炸、时钟掉到哭也见过有些团队全都顺序执行结果访存stall高到算力利用率只有百分之十几。真正走得通的路往往是先量化访存和同步瓶颈再用比较克制的乱序窗口配合访存队列、事件同步和编译器调度去解决问题。我自己现在看一个新的AI芯片设计第一反应不是问“你支不支持乱序”而是先要性能分析报告看访存stall、同步stall、片上互连拥塞各占多少。只有当这些阻塞点确实存在且占比足够大我才会去动乱序的念头。如果能把任务级流水、多warp切换、异步DMA这些更便宜的并行手段先榨干乱序其实可以永远只当一张备用底牌。反过来说当你的访存延迟特别深、同步粒度特别碎、编译器又很难提前调度时一个设计得当的Out-of-Order NPU/GPGPU确实能带来CPU那套方案给不了的灵活性和性能收益。希望这篇文章能帮你少走一点弯路。
前阵子连续聊了好几个AI芯片项目发现一个挺明显的趋势以前只有CPU设计组才碰的Out-of-Order乱序执行套路现在在NPU和GPGPU的架构讨论里出现得越来越频繁。有人觉得这太正常了CPU那套成熟方案直接平移过来就行也有人觉得乱序执行面积昂贵、功耗高在AI这种规则计算场景里纯属浪费。我自己的看法是这两种说法都只说对了一半。乱序不是银弹但它也不是CPU专属的老古董真正要做的是把“乱序”这个词放进NPU/GPGPU的真实痛点里重新理解一遍。所以这篇文章我打算从实际项目出发聊聊我理解的Out-of-Order NPU/GPGPU设计思路。我会解释为什么需要乱序、哪些CPU经验可以借鉴、哪些必须丢掉、以及真正落地时要怎么选参数、怎么排查问题。不管你是做架构设计的、写RTL的还是搞编译器对接的只要能跟着过一遍应该能少踩不少坑。1. 为什么NPU/GPGPU会开始认真考虑乱序执行1.1 CPU乱序那套东西为什么不能无脑搬过来先说清楚CPU里的乱序执行到底在干什么。乱序执行的本质是程序写出来的指令顺序叫“程序顺序”但硬件为了让流水线不白等会在不影响最终结果的前提下把后面的指令提前执行。为了做到这一点指令集架构里那些逻辑寄存器会被“重命名”到更多的物理寄存器上避免所谓WAR写后读和WAW写后写冒险调度器再从一大堆已经译码、已经确认依赖关系的指令里挑出能执行的那几条发射到运算单元去跑。最后还用一个重排序缓冲ROBReorder Buffer来记录指令的原始顺序保证异常能精确报告保证提交commit还是按顺序的。这套机制在CPU二维世界里确实很有效因为一个核心往往只有几条指令宽度逻辑寄存器数量也不多寄存器重命名带来的面积成本还在可控范围内。但CPU乱序有一个隐含前提指令宽度小、每周期能处理的事务量有限所以调度器可以集中式地维护一个几十项甚至上百项目的窗口。放到NPU和GPGPU上情况就完全不一样了。一条向量指令可能要同时操作几百个数据一条张量指令可能对应整个矩阵运算如果为每条指令都维护完整的物理寄存器重命名、为每个lane都保留一份寄存器的重命名映射面积和功耗会爆炸。所以我一直觉得直接照搬CPU乱序后端是条死路。真正有价值的思路是分析NPU/GPGPU在什么地方“等待”最严重然后把乱序用在刀刃上。1.2 NPU/GPGPU的真正瓶颈是存储墙不是分支预测CPU乱序要解决的核心问题很多缓存未命中、分支预测失败、访存延迟、长延迟浮点运算等等。但在AI芯片里计算模式高度规则绝大多数代码都是循环、矩阵乘、卷积、归一化这一类分支预测的负担其实远没有CPU那么重。如果你去剖一个NPU/GPGPU项目的性能瓶颈大概率都会看到同一个东西访存。这个现象在架构圈有个直白的词叫“存储墙”。以最常见的GEMM算子为例你要从DRAM或者HBM读入A矩阵、B矩阵中间计算单元可能很快就算完了但数据没到位你只能干等。HBM的访问延迟可能在几百个周期片上SRAM的容量又有限放不下大的中间结果。如果一条load指令没回来就卡住整个流水线那意味着后面的几百个周期里所有乘法器完全是空转的。有一种做法是“多线程隐藏延迟”这也是很多GPGPU的传统方案。同一个时钟周期里调度器可以频繁切换不同的warpA warp在等数据的时候B warp冲上去算。但这里面有个代价想要隐藏足够深的延迟你得有足够多的活跃线程每个线程又携带自己的寄存器状态寄存器文件被撑得特别大。而且随着算子越来越复杂比如Attention里的长序列访存单纯靠堆线程已经不够灵活。这个时候乱序执行的优势就出来了它并不要求你物理上放着几百个线程而是允许同一个线程流内的多条独立访存指令同时“在飞”把内存级并行度MLPMemory Level Parallelism拉高。1.3 乱序在NPU/GPGPU里到底解决什么问题把目标缩到“访存延迟、同步延迟、资源空闲”这三件事上就能回答这个问题了。第一个作用是隐藏访存延迟。顺序执行时load miss往往要阻塞后续所有指令而乱序可以让多条不相关的load/store提前准备好数据回来再唤醒真正等着那条数据去计算的指令。简单说每个内存级并行单位都在“替”计算单元争取时间。第二个作用是降低同步等待。AI芯片里常常有多个计算核、DMA引擎、卷积引擎并行跑一个算子算完要等另一个拿结果或者执行barrier保证所有线程都到达某个点。顺序体系下同步指令一上来整条流水线都得停。乱序执行如果配合“同步点不越过、同步之前的访存可以提前完成”这类策略就能把同步空窗期压缩。第三个作用是提升多级流水的利用率。NPU里往往不只是PE阵列还有DMA、向量单元、标量单元混在一起。指令乱序 异步派发可以让DMA搬运、计算、写回这几件事重叠起来而不是死板地“搬完一块算一块”。但要泼一盆冷水这类收益不是免费的。乱序执行本身需要更大的指令窗口、更多的寄存器文件、更复杂的调度器也会让时序收敛变难。所以设计前必须先量化确定你的系统里访存stall到底占了多少周期同步stall又占了多少然后才决定要不要上乱序、上到什么程度。2. 核心细节解析把乱序改造成适合并行引擎的样子2.1 不变量物理寄存器重命名与WAR/WAW消除既然要乱序寄存器重命名是绕不开的。先说一个最基础的原理。在顺序执行中如果第1条指令写R3第2条指令读R3这是真依赖RAW必须等如果第2条指令也写R3那么它和第1条之间就是输出依赖WAW顺序状态机里很容易处理但乱序后必须先判断谁是最后一个写的如果第1条读R3第2条写R3这是反依赖WAR乱序后第2条先写会破坏掉第1条要读的值。CPU的解法是给每个逻辑寄存器准备多个物理寄存器再用一张映射表记录“当前哪个物理寄存器代表这个逻辑寄存器”。每条需要写寄存器的指令在发射前就提前领走一个新的物理寄存器这样不同指令写同一个逻辑寄存器就变成了写不同的物理寄存器WAR和WAW冒险天然被消除。读操作则通过映射表找到最新的那个物理寄存器号。到了NPU/GPGPU上寄存器已经不是32位标量而是可能非常宽的向量寄存器甚至张量寄存器。如果不管哪条指令全都做物理寄存器重命名寄存器文件面积会大得离谱。常见的折中方案是只对“长延迟”的访存指令和“跨指令依赖必须做重命名”的指令做重命名其他纯计算指令可以沿用物理寄存器堆中的固定槽位或者采用一种RAID-like的轮转寄存器文件机制。轮转寄存器register rotation是一种在过去VLIW和部分GPGPU研究里出现过的思路。它把物理寄存器组织成环形缓冲区逻辑寄存器的编号是环上的相对位置。循环体每迭代一次整个环“转”一次硬件不需要复制寄存器内容只需要把基准指针偏移一下。这对AI里大量循环展开的场景非常友好因为循环迭代之间天然没有WAR/WAW用轮转寄存区比几十个物理寄存器端口灵活得多。另外要提醒的是NPU/GPGPU里普遍有谓词predicate寄存器用来控制向量lane的启停。重命名时不能只重命名数据寄存器谓词寄存器也要纳入管理。否则两条指令同时写同一个谓词寄存器乱序后可能会把后续向量操作的激活状态搞错。这个细节在实际验证中非常容易漏。2.2 调度器集中式还是分布式窗口放哪调度器是整个乱序执行引擎的心脏。CPU里的经典做法是统一保留站指令译码后全部进入一个大池子调度器每周期扫描所有满足条件的指令选择最老的几条发射。好处是窗口内所有指令可见坏处是复杂度随发射宽度和窗口大小急剧上升时钟频率很难做高。在NPU/GPGPU里我更推荐分布式调度。原因很简单一个芯片上基本都有多个计算簇Compute Cluster/SM/Tile如果做一个全局统一调度器意味着取指、译码、重命名、发射都要汇聚到同一个点线程同步握手就会变得极其昂贵。分布式思路是每个计算簇内部负责自己的指令窗口簇内再分成“访存调度”和“计算调度”两个队列。访存指令进了访存队列后它是乱序发射的计算指令要等它依赖的访存数据回来被唤醒才发射。数据回到某个物理寄存器后调度器会检查有哪些指令依赖这个寄存器然后送入发射阶段。发射宽度在这个场景里也要重新考虑。CPU往往追求每周期发射4-8条微操作但对NPU/GPGPU来说一条向量指令就已经相当于CPU几十条甚至上百条微操作的运算量。我见过不少项目一开始照着CPU习惯做四发射、双发射结果面积暴涨性能却上不来。真正靠谱的做法往往是“单发射、但发射一股很大很宽的指令”并且把调度重点放在访存指令的提前发起上而不是让计算单元同时塞进一条又一条向量指令。窗口放在哪里也值得斟酌。如果指令窗口放在取指之后、译码之前那你看到的是“未来指令”可以更早发现访存机会但可能会把分支指令、跳转指令的约束搞得非常复杂。放到译码之后每条指令已经确定操作数依赖调度器能更精准判断哪条访存指令没有依赖可以提前发射。绝大多数NPU/GPGPU乱序设计采用后者先译码再进入乱序窗口。甚至有些设计的窗口不是传统ROB而是“两段式队列”一段专门放还没解析地址的访存指令一段放等待唤醒的计算指令。2.3 存储访问与同步指令的乱序边界乱序执行最敏感的地方永远在访存和同步。访存指令一旦乱序不同地址之间的读写依赖需要硬件检查否则一个load可能踩到别人刚store的内存或者一个store覆盖了别人还没load的值。在CPU里Load/Store Queue承担这个检查任务它会记录每条访存指令的地址和状态并强制地址冲突的指令恢复顺序。NPU/GPGPU的访存队列设计得更复杂因为访存指令的操作数往往是向量地址一条指令能覆盖一整段连续内存所以队列既要检查地址范围有没有重叠又要维护多个处理器的缓存一致性。做设计的时候我建议优先把“同地址重叠”检查做得精简只需要判断区间是否相交不用做到CPU那种按cache line逐字节翻查的精细度。AI计算的访存模式高度规整绝大多数冲突是整块区间冲突区间的粗粒度检查已经能扛住大部分case。还有一个特别容易被忽视的点同步原语。NPU/GPGPU里的barrier、fence、atomic操作本质上是在定义“谁必须等谁”。乱序执行如果让某条barrier指令越过前面的load/store就破坏了同步语义。所以设计中一定要明确同步指令是整个乱序窗口里的“硬边界”。它可以不卡住所有计算但它在逻辑上必须等到前面所有被它约束的访存操作完成并且它自己不能被后面的普通访存指令越过。实现上最简单的方式有两种一种是给同步指令一个特殊token只有前面的所有访存都提交后token才释放另一种是单独开一条“同步流水线”同步指令不走普通访存队列走专用通道直接在提交阶段执行。我踩过的坑是一开始为了简化硬件把barrier当成普通store来处理结果两个warp互相等待barrier还没真正落地后面的load已经读到旧数据整个kernel结果全错。这种问题排查起来极其耗时间因为功能仿真有时候根本跑不出时序问题必须做带延迟注入的模型才能复现。3. 实操过程从架构参数到验证环境怎么落地3.1 一个可参考的框架与流水线流程聊完理论给一个我习惯用的中等规模NPU/GPGPU乱序设计框架做参考。假设芯片有16个计算簇Tile每个簇内有32个lane簇内支持最多1024个线程每个线程有自己的向量寄存器上下文。整体流水线阶段可以划为取指Fetch→ 译码Decode→ 重命名Rename→ 调度Schedule→ 发射Issue→ 执行Execute→ 写回Writeback→ 提交Commit这和CPU流水线看起来像但内部实现有不少差异。取指阶段要支持多warp的指令缓冲也就是说同时从多个warp取指令而不是单一PC译码阶段会把向量/张量指令拆成“访存部分”和“计算部分”的依赖关系但不会真拆成两条微指令而是记录成两个队列之间的连接关系。重命名阶段这里要做的事情比CPU少因为AI指令大量是向量运算很多warp内的lane共享寄存器映射所以重命名粒度可以做到“每warp一组寄存器号”而不是“每lane一个物理寄存器号”。调度阶段分两条线访存指令进入Load/Store Queue计算指令进入一个小的Wakeup/Select矩阵。Rename完的指令如果依赖还没就绪就会被挂在等待状态数据写回时会通过广播方式唤醒等它的指令。提交阶段在GPGPU里压力也不小。每个周期能提交几条指令、每条指令要不要更新PC、异常怎么处理都会影响整体吞吐。但好消息是AI负载对精确异常要求不那么高很多NPU甚至可以直接做到“不打断整块任务出错就报error由软件重跑整个kernel”这大大降低ROB复杂度。于是很多设计的ROB会被简化成一条条的完成位而不是CPU那种精确PC恢复机制。3.2 关键参数估算窗口深度、物理寄存器数、访存队列参数设计不能拍脑袋我习惯先用一个简单模型估算。核心目标是在目标访存延迟L个周期、平均发射吞吐为每周期I条指令的情况下至少需要多少条不相关指令“在飞”才能让流水线不被访存卡住。粗略公式如下需要隐藏延迟的最小并发数 L × I假设访存延迟是300周期目标平均每周期发射1条向量指令那你至少要有300条指令已经发射出去并且处于等待数据或者运行中状态。如果每条指令里平均有2个独立访存请求那么内存级并行需求就是600个并发访存。这个并发数会直接换算成指令窗口大小、物理寄存器数量、访存队列深度。给一个我自己常用的参数估算表格具体数值按16个簇、每个簇目标1GHz、访存延迟300周期、平均每秒跑1条混合向量/访存指令来估参数估算依据参考范围乱序窗口深度每簇需要隐藏的并发指令数 × 流水线级数 / 发射宽度64~256物理寄存器数每簇窗口深度 × 每条指令写物理寄存器的最大值 当前活跃上下文2048~8192Load/Store Queue深度同时存活的访存指令数 同步原语预留项32~128同步指令队列深度每簇内活跃的barrier/fence数目8~32每周期发射宽度硬件复杂度与时钟目标折中1~2这里要特别解释一下为什么窗口深度不是直接等于L×I。因为不是每条指令都会在窗口里待满L个周期有的计算指令很快就能执行完另外还有warp切换、任务级并行在帮你隐藏延迟。所以我算出来的300个并发数会被进一步折减到64~256。折减的幅度取决于负载里访存指令占比到底多高以及不同warp之间访存是否能真正重叠。如果占比很低窗口取128已经足够取太大纯属浪费寄存器。物理寄存器数则和指令写寄存器数量密切相关。向量指令写一个向量寄存器可能对应32个lane每个lane要有一个物理寄存器槽。假设窗口深度256每条指令最多写2个物理寄存器那么理想情况需要512个物理寄存器槽但因为要处理重命名后的临时变量、warp上下文的保存恢复实际往往要留1.5~2倍裕量所以范围放到2048以上并不夸张。访存队列深度我觉得宁可多不要少。因为访存指令一旦发射出去它的地址和状态就占用一个LSQ条目直到数据返回并写回。如果LSQ满了后面所有访存都得堵住乱序窗口再大也被憋死。常规经验是LSQ深度至少是窗口深度的一半同时为每个warp预留至少2~4个条目给同步原语。3.3 让软件与编译器配合乱序乱序硬件不是万能的软件和编译器如果不配合效果会大打折扣。最典型的问题是指令集层面没有表达“依赖关系”的手段。编译器如果把所有指令都标记成相互依赖那硬件再大的窗口也没用每周期只能在依赖链上慢慢爬。所以现代NPU/GPGPU指令集往往会引入显式的event/token机制。也就是一条指令可以“等某个事件计数器归零”再真正执行另一条指令可以“算完之后把某事件计数器减一”。编译器负责把跨block、跨指令流的依赖关系转换成一连串wait_event和signal_event。这样硬件乱序窗口看到的是更细粒度的依赖关系而不是一个笼统的barrier。编译器在做指令调度时也要注意一个原则尽量把访存指令提前。比如GEMM循环体里先算好下一轮A矩阵的地址尽早发load再算当前这一轮的乘加。虽然硬件能乱序但编译器如果把load排在很后面硬件窗口再深也只能等到译码之后才发现这条访存指令白白浪费了取指到译码那一段周期。另外不要滥用fence指令。很多程序员为了保证正确性会在每个循环里插fence。当硬件已经做了访存依赖检查后fence大多数是不必要的。fence插得越多乱序窗口越难开性能回落得越明显。还有一个容易被忽略的配合点动态形状。AI负载经常有输入尺寸不固定循环次数可能是运行时的值。编译器如果不知道一次循环要跑多久硬件的分支处理就会变保守。建议在指令集里支持“可断言的循环结束”通过谓词让循环体最后几次迭代不需要单独处理边界分支给乱序调度器省下不少分支误判矫正的开销。3.4 用事件驱动模拟器做早期验证乱序设计的验证不能等到RTL写完了再来我强烈建议先用事件驱动模拟器把整个微架构模型搭出来。这一步看起来多花了时间实际上能帮你省掉后面好几个月的返工。我自己常用C写一个轻量的周期近似模拟器模块上对应ROB、物理寄存器、访存队列、同步队列、各计算单元延迟模型。它不追求和RTL完全周期级一致但要求能准确反映“指令在哪一个阶段等了多少周期”。负载就用最典型的GEMM、Elementwise、Attention做benchmark。测的时候一定要注入随机延迟把HBM访问延迟设置成带抖动的分布而不是固定300周期否则很多边界问题在模拟阶段根本发现不了。模拟器里我最关注三个数发射队列空置率、访存队列满占用率、同步等待周期占比。如果发射队列空置率很高说明没有足够的可执行指令窗口太小或者依赖太重如果访存队列长期接近满说明内存级并行要求太高要么窗口需要控制要么bandwidth不够如果同步等待周期占比超过20%就要回头检查是不是barrier粒度太粗。早期模型验证还有个意想不到的好处它可以给编译器团队提供一个量化的“并行度目标”。比如某个算子理论上需要达到多少并行度才能跑满硬件编译器看到这个数字后就能决定怎么展开循环、怎么插event事件。这点在软硬件协同优化里特别重要不然两边各自埋头做最后系统合在一起性能对不上你们互相甩锅的时间可能比写代码还多。4. 常见问题与排查技巧实录4.1 乱序之后性能不升反降这是几乎所有团队都会遇到的第一道坎。模拟器显示乱序设计能提升20%结果真正跑起来比顺序版还慢。原因往往不是一个而是好几个叠在一起。最常见的是寄存器重命名开销太大。当物理寄存器端口成为瓶颈时每周期连发射一条指令都困难乱序窗口里的指令再多也发射不出去。这时候你会看到性能报告里“发射队列满”周期占比特别高。另一个典型原因是调度器延迟占用了关键路径。有些团队为了追求大窗口把调度器的Wakeup/Select矩阵做得很大组合逻辑长到时钟频率掉了20%。算下来窗口大了频率低了性能收益全部被抹掉。遇到这种情况我通常建议先把发射宽度降到1窗口缩小到原来的一半然后把时钟频率做上去。很多时候性能反而更好因为AI负载里真正依赖大窗口的场景没有想象中那么多。还有一个系统级原因是访存带宽已经饱和。乱序把访存指令提前系统里bank冲突、MSHR未命中率可能同步升高。看起来load被提前发起了但大家都挤在内存控制器门口排队平均延迟不减反增。这时候性能不升反降其实不是乱序的问题而是内存子系统没跟上需要降低MLP或者优化地址交错。4.2 死锁问题barrier、同步原语与乱序执行打架乱序执行引入最大的风险之一就是死锁。一个经典场景是这样的warp0在barrier处等待warp1到达但warp1在到达barrier之前需要读warp0写出的一个数据而warp0之所以没写出这个数据是因为它自己在等barrier释放。如果硬件允许barrier指令被拖到访存队列之后乱序完成这个环形等待就可能被触发。排查死锁时硬件里最好有一个“同步等待状态寄存器”能显示每个warp当前在等什么同步原语、等了多久。按我的经验死锁复现概率不一定高要靠随机延迟注入来逼它现形。一旦复现先看所有的barrier是否都严格遵守“不能被越过的边界”这一条再看是否有两个以上的同步事件互相等待对方释放资源。修复上有一个实用技巧给同步事件加“序号”。每个事件都带一个不断递增的tag只有当前面的地址访问完成且事件tag满足依赖后同步指令才允许提交。这个tag机制实现起来不复杂但能让硬件和验证环境都能精确定位是哪一对依赖导致死锁。另一个技巧是“超时看门狗”同步等待超过一定周期后直接抛异常并dump现场。真实硅片调试时这个机制救过我很多次否则卡死一次就要重新跑整个仿真成本太高。4.3 访存拥塞与局部性劣化乱序执行会让访存请求更早涌入内存系统如果设计不对局部性会被冲散。顺序执行时同一cacheline的访问往往挨在一起能合并成一次memory request乱序后提前发射的load可能来自不同cacheline打散了合并的机会导致内存事务数量增加带宽效率变差。解决思路是不要什么访存指令都一窝蜂乱序而是给访存发射加“合并优先”策略。调度器在准备发射load/store时先去检查访存队列里有没有地址相近的请求如果有就让它们尽量靠在一起做合并如果完全无关才考虑提前发射。另一种做法是把访存指令分组连续地址的向量访存天然是一个内存事务把它当成一个整体跨步很大的指针追逐型访问则严格等待地址解析。观察这个问题的性能计数器主要是MSHR占用率和内存控制器bank利用率。如果MSHR长期接近最大值说明有太多独立miss在飞。我通常会限制每个warp最多同时有4~8个未完成miss超过就不要再提前发射新的访存指令。这样虽然理论MLP降了一点但内存效率会大幅提升总吞吐反而更好。4.4 调试手段性能计数器 波形反推乱序设计的调试比顺序设计难一个数量级因为指令执行顺序随时在变。你很难像顺序流水线那样说“这条指令在第几个周期执行”它可能提前执行了也可能等了几百个周期。所以必须把“性能计数器”和“波形反推”结合起来用。性能计数器至少要覆盖这几类信号计数器事件含义调优方向issue_slots_empty发射槽为空提高窗口/指令级并行load_queue_full访存队列满增大LSQ或限制访存发射register_file_ports_conflict寄存器端口冲突增加端口或降低发射宽度sync_wait_cycles同步等待周期优化barrier粒度/编译器插入msrh_occupancyMSHR占用限制MLP优化局部性commit_width_avg平均每周期提交数检查后端瓶颈拿到这些计数器之后再翻波形。我会习惯在仿真器里给每个warp打一个“事件时间线”记录它从取指到提交的每一个关键节点进了调度窗口、被唤醒、发射、数据返回、提交。一旦性能有问题先把时间线拉出来找那个空档特别大的warp看看它卡在哪个阶段。如果大量时间卡在“唤醒后等发射”那是调度器或寄存器端口的问题如果卡在“数据返回前”那是访存延迟或MLP不够的问题如果卡在“同步等待”那是上游任务没算完需要编译器去调同步位置。另外如果条件允许建议对同步语义和访存一致性做形式化验证。这类问题靠仿真去“试”很痛苦因为组合空间太大。用属性检查把“barrier不能越过前面的global write”这类约束写成断言让验证工具去穷举。等这条断言确认通过后你再去调试性能问题会轻松很多。5. 最后想说的话说句实话乱序执行在NPU/GPGPU上并不是一个“有或没有”的问题而是一个“在哪一级、什么粒度、为了什么”的问题。我见过有些团队一上来就要做巨大乱序窗口结果面积爆炸、时钟掉到哭也见过有些团队全都顺序执行结果访存stall高到算力利用率只有百分之十几。真正走得通的路往往是先量化访存和同步瓶颈再用比较克制的乱序窗口配合访存队列、事件同步和编译器调度去解决问题。我自己现在看一个新的AI芯片设计第一反应不是问“你支不支持乱序”而是先要性能分析报告看访存stall、同步stall、片上互连拥塞各占多少。只有当这些阻塞点确实存在且占比足够大我才会去动乱序的念头。如果能把任务级流水、多warp切换、异步DMA这些更便宜的并行手段先榨干乱序其实可以永远只当一张备用底牌。反过来说当你的访存延迟特别深、同步粒度特别碎、编译器又很难提前调度时一个设计得当的Out-of-Order NPU/GPGPU确实能带来CPU那套方案给不了的灵活性和性能收益。希望这篇文章能帮你少走一点弯路。
