流水线中的大冒险
上一节说到,流水线中的分支预测本身是为了提高整条流水线的并行度,为此,CPU做了很多努力,例如乱序执行,甚至于流水线本身也是为了这个目的而诞生的。
和 我们编写一般程序一样,顺序执行总是最简单、最安全的,指令被一条接着一条地顺序执行,没有人会思考任何有关并发的隐患。但是一旦踏入并发编程的范畴,似 乎就开始变得一团糟,你需要考虑数据竞争、锁、内存等等一系列问题。和分支预测一样,有时候你会采用一些试探性的方法去处理并发中产生的问题,例如经典的 CAS(Compare And Swap)算法,可能成功可能失败,喜忧参半。
在流水线中也存在着类似的大冒险,典型的有三种:
数据冒险
结构冒险
控制冒险
对应的,也有一些方法去辅助CPU在这些冒险的过程中,尽可能地达到我们期望的结果。
一、数据冒险
数据冒险源于在流水线的乱序执行中,读写之间产生的数据依赖,例如写后读,如果在一条指令的读之前,刚好有另一条指令完成了对相同位置的写,那么按常理来说,读的指令读到的数据必须是刚被写入的那个值。
看起来是不是很眼熟?是的,这跟Java中的Happens-Before法则是一致的,扩展开的话,数据库中的一致性以及Java中的volatile,本质上都是在确保同样的效果。
我 们知道经典的CPU是通过ALU进行计算的,而数据的输入则在通用寄存器中,事实上为了支持流水线,在ALU和通用寄存器之间,还有一些额外的寄存器,这 些寄存器对程序员不可见,被称作流水线寄存器,它们的作用也很简单,保存在流水线的执行过程中,各个时钟周期的结果暂存。
对于经典的五级流水线来说,一条指令的执行周期要经过以下过程:
IF: Instruction Fetch – 取址
ID: Instruction Decode and register fetch – 译码
EX: Execution and effective address calculation – 执行
MEM: Memory access – 内存访问
WB: Write Back – 写回通用寄存器
那么试想一下,假设现在有两条指令的执行路径如下:
I1: IF – ID – EX – MEM – WB
I2: IF – ID – EX – MEM – WB
I1的结果在EX之后被写入流水线寄存器暂存,此时还没写入内存,也没写入通用寄存器。
这个时候I2在EX阶段要取I1的结果,按道理是拿不到的。
最简单的,I2等待2个时钟周期,等I1把结果写入通用寄存器后,再去读取。这是一种解决方式。
CPU还可能会采用被称作Register Forwarding的机制获取数据,简单来说就是I1的流水线寄存器中的数据直接转发作为I2的EX的输入,此时I2的EX就不会受到影响,并且避免了等待造成的浪费。
二、结构冒险
结构冒险是当CPU同时有多条指令要访问同一个硬件资源时造成的冲突。例如同时对内存的访问,但同时只能提供一条指令的访问。
结构冒险在早期的冯·诺依曼架构中是个问题,因为数据和指令是存在一起的,IF和MEM就会发生冲突。而现代处理器在L1 Cache层将指令和数据分开,分为L1 Cache(I)和L1 Cache(D),避免了这个竞态问题。
三、控制冒险
控制冒险和上一节说到的分支预测关系密切。
首先想象一下如果没有分支预测,那么当流水线遇到跳转语句时,它会认为跳转这个时间点开始进入新的起点,所有事先被执行的指令都不对。这时CPU需要插入若干个停顿周期,直到一切恢复原点。
某些处理器会通过插入NOP指令的方式来停顿若干个时钟周期,而某些处理器干脆排空所有的当前指令(被称作流水线冲刷(Pipeline Flush)。
除了分支预测,另一种优化方式是将插入的等待NOP指令改为不相关的乱序执行的有效指令,利用等待时间的开销。