基于BOOM FPGA的乱序CPU微架构流水线内部参数评测

评测目标

1. 修改物理寄存器数量，观测处理器相关参数及整体性能变化。预期会观察到，在以计算为主的测试程序中，处理器的性能会随着数量增加而提升。
2. 修改ROB条目数，观测处理器相关参数及整体性能变化。预期会观察到，在条件判断较多的控制密集型测试程序中，处理器的性能会随着数量增加而提升。
3. 修改发射宽度，观测处理器相关参数及整体性能变化。
4. 修改发射队列条目数，观测处理器相关参数及整体性能变化。

评测方法

​ 控制变量法：使用FPGA，修改BOOM架构的流水线内部参数，模拟测评程序在不同参数配置下的运行情况，对比结果，并进行分析。

评测环境

MediumBOOM参数（默认）

评测基准

• coremark

  类似于MIPS、Dhrystone，是目前在嵌入式CPU行业中普遍公认的性能测试指标标准。作为综合型基准评测程序，它提供一套测试单核处理器核心的方法。测试标准是在配置参数的组合下单位时间内运行的CoreMark程序次数（单位：CoreMark/MHz），该数字值越大则说明测试的性能越好，CoreMark具有特定的运行和报告规则，可以避免由于所使用的编译库不同而导致的测试结果难以比较。

  run sh script

  ./coremark 
  

  RISCV汇编代码文件

• SPEC CPU2006

  • 计算密集型

    • gobmk(445)

      模拟量子计算机的库文件，用来进行量子计算机应用的研究

      run sh script

      #!/bin/sh
       ./gobmk --quiet --mode gtp  < 13x13.tst 
      

      RISCV汇编代码文件

  • 控制密集型

    • gcc(403) 基于gcc V3.2,为AMDCPU生成机器码，输入文件较多，测试压力更大，对9组C代码进行了编译 run sh script

      #!/bin/sh
      gcc 166.i -o 166.s 
      

      RISCV汇编代码文件 输入数据文件 输出数据文件

    • hmmer(456) 使用HMMS(Hidden Markov Models，隐马尔科夫模型) 基因识别方法进行基因序列搜索 run sh script

      #!/bin/sh
      hmmer nph3.hmm swiss41
      

      RISCV汇编代码文件 ​输入数据文件1 ​输入数据文件2

  • I/0密集型

    • h264ref(464)

      处理编解码，需要读入较大的输入文件。

      run sh script

      #!/bin/sh
      ./h264ref -d foreman_ref_encoder_baseline.cfg 
      

编译选项

riscv64-unknown-elf-gcc/riscv64-unknown-linux-gnu-gcc -static -O2 -o <target> <src> -lm

如果是C++源文件，则使用相应的g++编译器，都是静态编译，统一使用版本为9.2.0的编译器，2级编译优化。

评测指标

​ 由于本测评修改了寄存器数量，ROB条目和发射宽度和发射队列条目，因此主要选择了以下11个硬件性能事件作为评测指标，使用HPC性能计数器进行统计。

• cycle

• inst

• int physical register full

• fp physical register full

• mem issued insts

• int issued insts

• fp issued insts

• mem issue queue full

• int issue queue full

• fp issue queue full

• rob queue full

事件信号设计

• Event Set # 0

• sigs

  	  used_event_sigs(0) := 1.U  //cycles
        used_event_sigs(1) := RegNext(PopCount(rob.io.commit.arch_valids.asUInt)) // commit inst
        used_event_sigs(2) := Mux(rename_stage.io.fl_full, 1.U, 0.U) //int physical reg
        used_event_sigs(3) := Mux(fp_rename_stage.io.fl_full, 1.U, 0.U)             //fp physical reg
        used_event_sigs(4) := RegNext(PopCount(mem_iss_unit.io.iss_valids))
        used_event_sigs(5) := RegNext(PopCount(int_iss_unit.io.iss_valids))
        used_event_sigs(6) := RegNext(PopCount(fp_pipeline.io.debug_iss_valids))
        used_event_sigs(7) := Mux(mem_iss_unit.io.event_empty, 1.U, 0.U)
        used_event_sigs(8) := Mux(int_iss_unit.io.event_empty, 1.U, 0.U)
        used_event_sigs(9) := Mux(fp_pipeline.io.debug_issue_full, 1.U, 0.U)
        used_event_sigs(10) := Mux(rob.io.full, 1.U, 0.U)
  

评测结果

Coremark

大致运行时间

real 6m44.374s user 6m37.770s sys 0m0.421s

下表为修改ROB条目数的参数后的性能及相关事件统计

下表为修改整数型物理寄存器数目的参数后的性能及相关事件统计

下表为修改浮点型物理寄存器数目的参数后的性能及相关事件统计

下表为修改发射宽度的参数后的性能及相关事件统计

下表为修改发射队列条目数的参数后的性能及相关事件统计

gcc

大致运行时间

real 66m56.734s user 65m26.152s sys 0m34.367s

下表为修改ROB条目数的参数后的性能及相关事件统计

下表为修改整数型物理寄存器数目的参数后的性能及相关事件统计

下表为修改发射宽度的参数后的性能及相关事件统计

下表为修改issue queue条目参数后的性能及相关事件统计

gobmk

大致运行时间

real 151m28.938s user 149m15.153s sys 0m14.211s

下表为修改ROB条目参数后的性能及相关事件统计

下表为修改整数型物理寄存器数目的参数后的性能及相关事件统计

下表为修改发射宽度的参数后的性能及相关事件统计

下表为修改issue queue条目参数后的性能及相关事件统计

hmmer

下表为修改ROB条目参数后的性能及相关事件统计

下表为修改整数型物理寄存器数目的参数后的性能及相关事件统计

下表为修改发射宽度的参数后的性能及相关事件统计

下表为修改issue queue条目参数后的性能及相关事件统计

h264ref

大致运行时间

real 267m22.919s user 258m47.163s sys 0m26.569s

下表为修改ROB条目参数后的性能及相关事件统计

下表为修改整数型物理寄存器数目的参数后的性能及相关事件统计

下表为修改发射宽度的参数后的性能及相关事件统计

下表为修改issue queue条目参数后的性能及相关事件统计

评测分析

coremark

• IPC随ROB队列容量增大，先增后不变，ROB full事件次数呈现同样趋势，说明ROB条目为128时已经饱和，ROB容量对性能的提升达到瓶颈。

• 该基准程序中，物理寄存器的增加，对IPC的提升相比其他基准还是更明显，但也只有不到0.5%，这说明BOOM架构中，流水线内部参数寄存器数量不是制约性能提升的关键路径。
• coremark的IPC随着发射队列容量的增加而提升相比于其他程序也是比较明显的，但是提升幅度最高也没有超过2%，这说明目前的发射队列容量基本已经够满足coremark程序这种数量级的指令的基准的需求

gcc

• gcc基准程序对于ROB，物理寄存器数量，发射队列这三种参数的敏感度都较低，IPC的提升幅度太小，这说明这些流水线内部参数可能不是影响gcc性能的关键所在。

gobmk

• 该基准程序仅对于物理寄存器数量参数相对其他程序较敏感，但最高不超过0.2%，说明寄存器数量在默认配置下已经够用，对性能基本无影响。

hmmer

• hmmer性能随着ROB容量的增加而提升，归因于分支跳转和load等影响乱序性能的操作比较频繁，容易给ROB带来较大压力。

h264ref

• 该基准程序IPC受到发射队列容量的影响最大，提升幅度超过了10%，但在将发射队列提升到2倍后，IPC基本不再提升，观察到发射队列Full次数也不再有明显下降，这说明这时候的发射队列不再是性能关键路径，这或许是它是memory类型应用的缘故，性能关键路径最重要的一环在load队列，这是刘欢师兄测试的参数。
• 该基准程序在其他参数上IPC的变化趋势也是所有已测基准中更明显的，这可能是其指令数更庞大，指令类型更复杂，存在较多影响乱序流水性能的操作带来的效果，需要进一步更具体的研究。

综合对比分析

根据以上各个参数的IPC的变化图，以及一些相关事件统计值的变化趋势，可以得出以下的初步分析：

• 不同的基准程序由于各类指令分布特点的不同，IPC与各类参数的关系很复杂，比如说，对于ROB条目数增加带来的性能提升幅度就很不同，hmmer，h264ref等程序更可能因为ROB队列容量增加带来性能提升，因为这些程序分支跳转和load等影响乱序性能的操作比较频繁，容易给ROB带来较大压力，这也能从ROB Full Events的减少体现出ROB队列容量的重要性，较大容量会减少流水线的停顿频率，这项参数的评测结果符合预期。
• 所测的h264ref等基准程序对于发射队列条目增加带来的性能提升比较明显，有的ipc提升甚至达到了10%以上，说明它们对于发射队列的容量需求比较敏感，
• 基本上大部分所测的基准程序的ipc都会因为物理寄存器数量增加而增大，但是提升幅度都较小，最高的都不到0.5%，而且从每个基准程序在测试时统计到寄存器full事件次数可以发现，该数值降低的趋势太小，这说明BOOM默认配置基本上可以满足大部分程序的需求，没有必要再为了一点点小的性能提升而花费太大代价来增加物理寄存器的数量，故整数寄存器80个，浮点寄存器64个基本上可以满足所测的大部分程序的性能需求
• Spec基准程序相比coremark而言，因为指令数目的增加，IPC和ROB队列容量、发射队列容量等参数的关系更加明显，特别是h264ref基准，观察到其输入文件较大，可能有较大load操作，对乱序流水线性能有很大影响，这让其几乎和每种参数都有较强的相关性。
• 所测的大部分基准程序，在发射宽度从默认的4到提升一倍的过程中IPC变化不太明显，相对于发射宽度为3的提升幅度最高不到3%，这说明发射宽度不在影响性能的关键路径上，平均来看发射宽度取默认的4是较好的选择。