性能优化方法: 拍脑袋 vs. 方法论

性能优化一直以来是同学们非常向往的环节

• 看着自己设计的处理器跑得越来越快, 心里充满成就感

但如果你费了九牛二虎之力的优化措施, 反而带来性能倒退, 你是否会感到沮丧?

• 拍脑袋的决策: 在RTL层次正确实现功能 != 性能提升

性能评估的第一步: 选benchmark

• 拍脑袋 = 凭直觉, 科学方法 = 量化分析
  • 在系统领域, 用数据说话是基本素养

• 需要一个量化的指标来衡量 “性能”
  • 性能高 = 跑得快 -> 程序的执行时间!

各种各样的benchmark

• Linpack(高性能计算), MLPerf(机器学习), CloudSuite(云计算), SPEC CPU(通用计算)…
  • SPEC CPU 2006覆盖的领域包括: 垃圾邮件检测, 压缩, 编译, 组合优化, 人工智能搜索, 基因序列搜索, 量子计算, 视频编解码, 以太网协议模拟, 寻路算法, 文本处理, 流体力学, 量子化学, 生物分子, 有限元分析, 线性规划, 影像光线追踪, 计算电磁学, 天气预报, 语音识别…
  • SPEC CPU 2017新增了生物医学成像, 3D渲染和动画, 采用蒙特卡罗树搜索的人工智能围棋程序(很大概率受2016年AlphaGo的影响)

适合教学的benchmark

一些需求:

• 规模不算太大, 在模拟器甚至在RTL仿真环境中的执行时间不到2小时
  • SPEC CPU在x86真机上执行都要几个小时, RTL仿真算下来要7年!
• 可在裸机环境中运行, 无需启动Linux
• 程序具有一定代表性
  • 不像CoreMark和Dhrystone那样采用合成程序(用代码片段拼接)

如何优化运行时间?

需要分析运行时间受哪些因素影响

        time      inst     cycle     time
perf = ------- = ------ * ------- * -------
        prog      prog      inst     cycle

给定一个程序, 性能优化的方向

• 减小inst/prog - 即减少动态指令数, 可在仿真环境中统计
  • 优化措施: 改进算法, 编译优化, 采用行为更复杂的指令集
• 减小cycle/inst(CPI) - 即增加IPC, 统计周期数后可计算得到
  • 优化措施: 体系结构优化(我们关注的主题)
• 减小time/cycle - 即增加主频, 可查看综合报告获得
  • 优化措施: 电路关键路径优化, 后端物理设计优化

如何提升IPC?

统计得到的IPC还是无法指导我们如何优化IPC

• 需要分析IPC受哪些因素影响 -> 重新审视处理器如何执行指令

       /--- frontend ---\    /-------- backend --------\
                                  +-----+ <--- 2. computation efficiency
                             +--> | FU  | --+
       +-----+     +-----+   |    +-----+   |    +-----+
       | IFU | --> | IDU | --+              +--> | WBU |
       +-----+     +-----+   |    +-----+   |    +-----+
          ^                  +--> | LSU | --+
          |                       +-----+
1. instruction supply                ^
                    3. data supply --+

将处理器分为前端和后端, 要提升处理器的执行效率:

1. 前端需要保证指令供给
   • 影响所有指令 - 指令都没有, 整个处理器只能空转
2. 后端需要保证计算效率和数据供给
   • 大部分计算指令的执行效率取决于相应功能单元, 如乘除法, 浮点等
   • 访存指令的执行效率取决于LSU, 尤其是load指令需要等待数据返回

如何量化评估指令供给, 计算效率和数据供给?

性能事件(performance event): 在电路层次与性能指标相关的具体事件

• 如果 “IFU取到指令”的事件经常发生, 则说明指令供给能力强
• 如果 “LSU取到数据”的事件经常发生, 则说明数据供给能力强
• 如果 “EXU完成计算”的事件经常发生, 则说明计算效率高

寻找性能瓶颈: 阿姆达尔定律(Amdahl’s law)

性能瓶颈究竟在哪里? 哪些优化工作是值得做的? 优化工作的预期性能收益是多少?

Amdahl’s law可以告诉我们答案:

The overall performance improvement gained by optimizing a single part of a system is
limited by the fraction of time that the improved part is actually used.

优化系统中某部分所获得的总体性能收益, 受限于那部分实际使用的时间占比.
公式表示: 假设系统某部分实际使用的时间占比是p, 该部分在优化后的加速比是s, 则整个系统的加速比为
f(s) = 1 / (1 - p + p / s)

<------- A --------><-B->
++++++++++++++++++++ooooo   原程序
++++++++++++++++++++o       将B优化5倍
++++++++++++++++++++        将B优化5000倍, 优化后B的运行时间很短
++++++++++ooooo             将A优化2倍

抛开workload谈优化就是耍流氓

这是一则来自软件工程领域的忠告

• 也适用于处理器体系结构优化
• 优化占比50%的部分, 和优化占比5%的部分, 效果天差地别

校准访存延迟

性能计数器的统计结果指导我们得出优化方案

• 如果性能计数器的统计结果不准确, 开展优化的实际效果可能不明显, 甚至带来性能倒退
• 在 “一生一芯”中, 准确 = 接近真实芯片的情况

开放讨论: FPGA的作用

有同学认为FPGA肯定比仿真 “先进”, 但应该结合使用场景来分析

1. 作为功能测试的环境: 教学
   • FPGA的作用是加速仿真过程, 不需要校准访存延迟
   • 需要满足: FPGA比特流生成时间 + FPGA运行时间 < verilator编译时间 + verilator运行时间
     • FPGA比特流生成时间 ~ 小时量级, verilator编译时间 ~ 分钟量级
     • 因此verilator运行时间需要达到小时量级, 才能加速
2. 作为性能测试的环境, 同时也作为目标平台: 比赛或科研项目
   • 不需要校准访存延迟
3. 作为性能测试的环境, 但目标是流片: 企业产品研发, “一生一芯”学习
   • 期望通过FPGA得出的性能数据尽可能与真实芯片一致
   • 校准访存延迟是不可或缺的

经典体系结构的4类优化方法

1. 局部性 - 利用数据访问性质提升指令/数据供给的效率. 代表性技术:
   • 缓存, 今天的主题
2. 并行 - 多个实例同时工作, 提升系统整体的处理能力. 代表性技术:
   • 指令级并行 - 同时执行多条指令: 流水线, 多发射, VLIW, 乱序执行
   • 数据级并行 - 同时访问多个数据: SIMD, 向量指令/向量机, GPU
   • 任务级并行 - 同时执行多个任务: 多线程, 多核, 多处理器, 多进程
3. 预测 - 先投机, 后检查, 猜对就赚了. 代表性技术:
   • 分支预测
   • 缓存预取
4. 加速器 - 用专用部件执行特定任务. 代表性技术:
   • 各种定制化的加速器IP
   • 自定义扩展指令
     • 乘除法器 - 将乘除法指令视为基础指令的扩展

重新审视处理器体系结构设计

一名合格的处理器架构师应该具备如下能力:

• 理解程序如何在处理器上运行
• 对于支撑程序运行的特性, 能判断它们适合在硬件层次实现, 还是适合在软件层次实现
• 对于适合在硬件层次实现的特性, 能提出一套在各种因素的权衡之下仍然满足目标要求的设计方案

存储层次结构 - 不同存储介质的物理性质不同

         access time     /\        capacity    price
                        /  \
            ~1ns       / reg\        ~1KB     $$$$$$
                      +------+
            ~10ns    /  DRAM  \      ~10GB     $$$$ (20元/GB)
                    +----------+
            ~10ms  /    disk    \    ~1TB       $$  (固态0.683元/GB, 机械0.139元/GB)
                  +--------------+
            ~10s /      tape      \  >10TB       $  (0.033元/GB)
                +------------------+

集成并组织多种存储器, 在整体上达到容量大, 速度快, 成本低的效果

一个重要的观察 - 局部性原理

架构师发现, 程序对内存的访问存在若干规律

1. 时间局部性 - 访问某存储单元后, 短时间内可能再次访问它
2. 空间局部性 - 访问某存储单元后, 短时间内可能访问其相邻存储单元

存储层次结构是局部性原理的重要应用

即使慢速存储器容量大, 程序在一段时间内访问的存储单元相对集中

存储层次结构的诀窍: 将各种存储器按层次排列, 上层存储器速度快但容量小, 下层存储器容量大但速度慢

• 先访问上层存储器, 若命中, 则直接访问当前层级的数据;
• 若缺失, 则访问下一层级, 下层将目标数据及其相邻数据传递给上层
  • 传递给上层 - 利用了时间局部性
  • 相邻数据 - 利用了空间局部性

cache - 寄存器和DRAM之间的存储层次

               access time       /\          capacity    price
                                /  \
                  ~1ns         / reg\          ~1KB     $$$$$$
                              +------+
         ----->   ~3ns       /  cache \        ~30KB     $$$$$
                            +----------+
                  ~10ns    /    DRAM    \      ~10GB     $$$$
                          +--------------+
                  ~10ms  /      disk      \     ~1TB      $$
                        +------------------+
                  ~10s /        tape        \  >10TB       $
                      +----------------------+

关键思想: 在寄存器和DRAM之间加一层存储器

• 访存时, 先访问cache, 若命中, 则直接访问
• 若缺失, 则先将数据从DRAM读入cache, 然后再访问cache中的数据
• 可以提升指令供给和数据供给的效率

设计cache需要考虑的问题

为了方便描述, 将从DRAM读入的数据称为一个数据块

• cache中存放的数据块称为cache块

设计cache需要解决如下问题

1. 数据块的大小应该是多少?
   • 即以多少数据为单位进行管理?
2. 如何检查访存请求是否在cache中命中?
3. cache的容量通常比DRAM小, 如何维护cache块和DRAM中数据块之间的映射关系?
   • cache满了后怎么办?
4. CPU可能会执行写操作, 从而更新数据块中的数据, cache应如何维护?

简易指令cache的设计

先考虑指令缓存icache(instruction cache), 暂不考虑写操作

• 块大小先取4B
  • 若小于4B, 取一条指令要进行多次访存, 效率太低
  • 大于4B是否更合适, 后续探索

简易指令cache的设计(2)

• 用简单的直接映射(direct-mapped)方式维护数据块之间的映射关系
  • 假设cache可存放k个cache块, 则将内存地址为addr的数据块读入编号为(addr/4)%k的cache块
  • 多个数据块可能会映射到相同的cache块
    • 根据局部性原理, 将来更大概率访问新块, 故应用新块替换旧的

块大小 = 16B, 可存放4096个cache块

 31     16 15    4 3      0
+---------+-------+--------+
|   tag   | index | offset |
+---------+-------+--------+

cache的实现

icache的工作流程:

1. IFU向icache发出取指请求
2. icache根据请求的index部分索引出一个cache块, 判断其tag与请求的tag是否相同, 并检查该cache块是否有效. 若是, 则命中, 跳转到第5步
3. 通过总线在DRAM中读出请求所在的数据块
4. 将该数据块填入相应cache块中, 更新元数据
5. 向IFU返回取出的指令

测试 vs. 证明

• 测试 - 判断给定的输入是否能运行正确
• 证明 - 判断所有的输入是否能运行正确

求解器 - 把问题当作方程来解

在给定约束条件下寻找可行解的数学工具(类似解方程组或线性规划)

Z3是一个SMT(Satisfiability Modulo Theories, 可满足性模理论)求解器

• 求解包含实数, 整数, 比特, 字符, 数组, 字符串等内容的命题是否成立
• 能将问题表达成一阶逻辑语言的某个子集, 就能让SMT求解器求解
• 广泛应用于定理自动证明, 程序分析, 程序验证和软件测试等领域

#!/usr/bin/python
from z3 import *

x = Real('x')  # 定义变量
y = Real('y')
z = Real('z')
s = Solver()
s.add(3*x + 2*y - z == 1)    # 定义约束条件
s.add(2*x - 2*y - 4*z == -2)
s.add(-x + 0.5*y - z == 0)
print(s.check())  # 求是否存在可行解: sat
print(s.model())  # 输出可行解: [y = 14/25, x = 1/25, z = 6/25]

形式化验证 = 把验证结果当作方程来解

一类基于求解器的验证方法

• 变量: 测试输入
• 约束条件: DUT
• 求解目标: 至少一个assert()不成立

把上述内容转换成求解器识别的语言, 让求解器寻找是否存在可行解

• 例如, 若某设计中有assert(cond1)和assert(cond2), 则尝试求解是否存在输入使得!cond1 || !cond2成立

Chisel重磅福利

import chisel3._
import chisel3.util._
import chiseltest._
import chiseltest.formal._
import org.scalatest.flatspec.AnyFlatSpec

class Sub extends Module {
  val io = IO(new Bundle {
    val a = Input(UInt(4.W))
    val b = Input(UInt(4.W))
    val c = Output(UInt(4.W))
  })
  io.c := io.a + ~io.b + Mux(io.a === 2.U, 0.U, 1.U)

  val ref = io.a - io.b
  assert(io.c === ref)
}

class FormalTest extends AnyFlatSpec
  with ChiselScalatestTester with Formal {
  "Test" should "pass" in {
    verify(new Sub, Seq(BoundedCheck(1)))
  }
}

BoundedCheck()参数用于指定SMT求解器需要证明的周期数

• BoundedCheck(4)表示让SMT求解器尝试证明DUT在复位之后的4个周期内, 在任意输入信号下都不违反assert()
• 对于组合逻辑电路, 采用 BoundedCheck(1)即可

用形式化验证测试icache

class CacheTest extends Module {
  val io = IO(new Bundle {
    val req = new ...
    val block = Input(Bool())
  })

  val memSize = 128  // byte
  val mem = Mem(memSize / 4, UInt(32.W))
  val dut = Module(new Cache)

  dut.io.req <> io.req

  val dutData = dut.io.rdata
  val refRData = mem(io.req.addr)
  when (dut.io.resp.valid) {
    assert(dutData === refData)
  }
}

一些需要补充的细节:

• 屏蔽写操作, 可以将写使能相关的信号置为0
• 让cache缺失时从mem中读出数据
  • 由于DUT不产生写操作, 因此可与REF使用相同的存储器
• DUT和REF返回数据的时机不同, 需要同步后再通过assert()检查
  • 又是状态机

cache性能的评价指标

需要有个评价指标来评估优化的效果

• 缓存技术主要用于提升访存效率, 应该通过访存相关的指标来评价
• 通常采用AMAT(Average Memory Access Time)作为评价指标

AMAT = p * access_time + (1 - p) * (access_time + miss_penalty)
     = access_time + (1 - p) * miss_penalty

• p - 命中率
• access_time - 访问时间, 即从接收请求到得出命中结果所需的时间
• miss_penalty - 缺失代价, 此处即访问DRAM的时间

cache缺失的3C模型

提升命中率 = 降低缺失率, 需要先了解cache的缺失有哪些原因

计算机科学家Mark Hill在其1987年的博士论文中提出3C模型, 刻画了cache缺失的3种类型:

1. Compulsory miss, 强制缺失
   • 定义: 在一个容量无限大的cache中所发生的缺失
   • 表现: 在第一次访问一个数据块时所发生的缺失
2. Capacity miss, 容量缺失
   • 定义: 不扩大cache容量就无法消除的缺失
   • 表现: 因cache无法容纳所有所需访问的数据而发生的缺失
3. Conflict miss, 冲突缺失
   • 定义: 除上述两种原因外引起的缺失
   • 表现: 因多个cache块之间相互替换而发生的缺失

降低缺失率

• 降低Compulsory miss: 需要在访问某数据块前就将其读入cache中
  • 当前工作流程不支持, 需要添加新机制才能实现: 预取(prefetch)
  • 需要根据profiling结果决定是否值得实现

全相联(fully-associative)组织方式

每个数据块都可存放到任意cache块中

• 具体位置由替换算法根据每个cache块当前的访问状态决定
  • 替换算法需要选择一个将来最不可能被访问的cache块(预测未来)
• 常见的替换算法: FIFO, LRU, random…

    31              m m-1    0
   +-----------------+--------+
   |       tag       | offset |
   +-----------------+--------+

组相联(set-associative)组织方式

• 给所有cache块分组, 在组间通过直接映射方式选出一个组, 然后在组内通过全相联方式选出一个cache块
  • 每个数据块都可以存放到组号为(tag % 组数)中的任一个cache块
  • 若每组有w个cache块, 则称为w路组相联

    31    m+n m+n-1   m m-1    0     n = log2(w)
   +---------+---------+--------+
   |   tag   |  index  | offset |   index: 组索引
   +---------+---------+--------+

• 判断命中时, 只需要与组内所有cache块检查其tag是否匹配即可
  • w不大时, CAM的开销可以接受

块大小的选择

• cache块增大
  • ✔️ 降低tag的存储开销
  • ✔️ 能存放更多相邻数据, 更好地捕捉到程序的空间局部性
  • ✖️ 缺失代价上升
  • ✖️ cache块的数量更少, 增加Conflict miss

// 2个大小为4的cache块
               1111       2222        cache
|--------------oooo-------oooo-----|  memory, `o`为程序访问的热点数据

// 1个大小为8的cache块
               11111111               cache
|--------------oooo-------oooo-----|  memory

缺失代价的分析

给SDRAM的访问时间建立如下的简单模型

+------------------------ arvalid有效
|   +-------------------- AR通道握手, 接收读请求
|   |       +------------ 状态机转移到READ状态, 并向SDRAM颗粒发送READ命令
|   |       |     +------ SDRAM颗粒返回读数据
|   |       |     |   +-- R通道握手, 返回读数据
V a V   b   V  c  V d V
|---|-------|-----|---|

• 对于单个总线传输事务, 开销是a+b+c+d
• 若cache块大小是总线数据位宽的4倍, 则缺失代价为4(a+b+c+d)
  • 其中存在优化的机会

总线的突发读写

与SDRAM颗粒类似, AXI总线也支持 “突发传输”(burst transfer)

• 在一次总线传输事务中包含多次连续的数据传输
• 通过axburst和axlen信号指示, 具体细节RTFM

  a     b      c    d
|---|-------|-----|---| <-------------------- 第1个节拍
                  |-----|---| <-------------- 第2个节拍
                        |-----|---| <-------- 第3个节拍
                              |-----|---| <-- 第4个节拍

与重复4次的总线传输事务相比:

• AR通道只需要进行一次握手, 开销可节省3a
• 若还有地址连续的READ命令, SDRAM控制器的状态机则直接转移到READ状态继续发送, 开销可节省3b
• 回复R通道的同时可发送下一次READ命令, 开销可节省3d

设计空间探索

缓存有那么多参数, 那么多策略, 怎么选合适?

• 特别地, 会不会有的组合不相容反而导致性能下降?
• 要想选一个还不错的组合, 需要评估它们效果如何

快速估算cache的性能表现

在评估cache的性能表现时, 通常我们会选取指定的benchmark

• 可以统计某程序cache缺失需要等待的总时间TMT(Total Miss Time)
  • TMT = 缺失次数 * 缺失代价, TMT越小, IPC越大

功能模拟器即可满足需求

没有必要每次都完整运行程序, 只需要一个简单的功能模拟器cachesim

• 用C代码模拟cache的工作流程
• 接收指令流的PC序列(简化版itrace), 通过维护元数据统计缺失次数

模拟器和体系结构研究

在复杂的项目中, 设计空间非常大, 评估一组参数的时间开销耗时也长

• 在NPC上跑microbench train规模(几小时) vs. 在香山上跑SPEC CPU ref规模的片段(1周)

如何能快速评估不同设计参数的性能表现, 是一个至关重要的问题

• 模拟器对体系结构设计来说非常重要

真正的处理器设计流程

需求分析 -> 结构设计 -> 逻辑设计 -> 功能验证 -> 性能验证 -> 性能优化 -> 面积评估/时序分析

• 我们用icache作为例子贯穿了整个流程
• 一个不完整的知识链条
  • 需求分析 <- 性能评估 <- benchmark, 访存延迟校准 <- SoC <- NPC
  • 结构设计 <- 经典体系结构的4类优化方法 <- 缓存 <- 总线
  • 逻辑设计 <- 电路, RTL编码
  • 功能验证 <- DiffTest, 形式化验证 <- C语言, 模拟器, 仿真环境
  • 性能验证 <- cachesim <- C语言, 模拟器, 性能计数器
  • 性能优化 <- 设计空间探索 <- C语言, 模拟器, 软件优化, Linux脚本
  • 面积评估/时序分析 <- 电路, yosys-sta

如果只会写RTL代码, 无法做出一个好的处理器