流水线中的大冒险

流水线中的大冒险

上一节说到,流水线中的分支预测本身是为了提高整条流水线的并行度,为此,CPU做了很多努力,例如乱序执行,甚至于流水线本身也是为了这个目的而诞生的。

和 我们编写一般程序一样,顺序执行总是最简单、最安全的,指令被一条接着一条地顺序执行,没有人会思考任何有关并发的隐患。但是一旦踏入并发编程的范畴,似 乎就开始变得一团糟,你需要考虑数据竞争、锁、内存等等一系列问题。和分支预测一样,有时候你会采用一些试探性的方法去处理并发中产生的问题,例如经典的 CAS(Compare And Swap)算法,可能成功可能失败,喜忧参半。

在流水线中也存在着类似的大冒险,典型的有三种:

数据冒险

结构冒险

控制冒险

对应的,也有一些方法去辅助CPU在这些冒险的过程中,尽可能地达到我们期望的结果。alt

一、数据冒险

数据冒险源于在流水线的乱序执行中,读写之间产生的数据依赖,例如写后读,如果在一条指令的读之前,刚好有另一条指令完成了对相同位置的写,那么按常理来说,读的指令读到的数据必须是刚被写入的那个值。

看起来是不是很眼熟?是的,这跟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指令改为不相关的乱序执行的有效指令,利用等待时间的开销。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注