探秘X86架构CPU流水线

第一个改变是指令从内存中取到处理器的指令缓存的过程。现代处理器能够检测何时会产生一个大的分支跳转(比如函数调用)，然后提前将跳转目的地的指令加载到指令缓存中。

译码级有一些略微的修改。不同于以往处理器仅仅译码指令指针指向的指令，奔腾 Pro 处理器每一个时钟周期最多能译码 3 条指令。现今的处理器(2008-2013 年)每个时钟周期最多可以译码 4 条指令。译码过程产生很多小片的操作，被称作微指令(micro-ops, ?-ops)。

下一级(或者好几级)被称为微指令翻译，接着是寄存器重命名(register aliasing)。许多操作同时执行，并且执行的顺序是乱序的，所以有可能出现一条指令读一个寄存器的同时，另外一条指令正在对这个寄存器进行写操作。在处理器内部，这些原始的寄存器(如 AX,BX,CX,DX 等)被翻译(或者重命名)成为内部的寄存器，而这些寄存器对程序员是不可见的。寄存器和内存地址需要被映射到一个临时的地方用于指令执行。当前每个始终周期可以翻译 4 条微指令。

当微指令翻译完成后，它们会进入一个重排序缓存(Reorder Buffer, ROB)，ROB 可以存储最多 128 条微指令。在支持超线程的处理器上，ROB 同样可以重排来自两个虚拟处理器的指令。两个虚拟处理器在 ROB 中将微指令汇集到一个共享的乱序执行部件中。

这些微指令已经准备好可以执行了。它们被放在保留站中(Reservation Station, RS)。RS 最多可以同时存储 36 条微指令。

现在才开始乱序执行部件神奇的部分。不同的微指令在不同的执行单元中同时执行，而且每个执行单元都全速运行。只要当前微指令所需要的数据就绪，而且有空闲的执行单元，微指令就可以立即执行，有时甚至可以跳过前面还未就绪的微指令。通过这种方式，需要长时间运行的操作不会阻塞后面的操作，流水线阻塞带来的损失被极大的减小了。

奔腾 Pro 的乱序执行部件拥有 6 个执行单元：两个定点处理单元，一个浮点处理单元，一个取数单元，一个存地址单元，一个存数单元。这两个定点处理单元有所不同，一个能够处理复杂定点操作，一个能同时处理两个简单操作。在理想状况下，奔腾 Pro 的乱序执行部件可以在一个时钟周期内执行 7 条微指令。

现今的乱序执行部件仍然拥有 6 个执行单元。其中取数单元，存地址单元，存数单元没有变，另外 3 个多少发生了变化。这三个执行单元都可以执行基本算术运算，或者执行更复杂的微指令。但每个执行单元擅长执行不同种类的微指令，使得它们能更高效的执行运算。在理想状况下，现今的乱序执行部件可以在一个时钟周期内执行 11 条微指令。

最终微指令会得到执行，在经过数个流水级之后，最终会退出流水线。这时，这条指令完成并且递增指令指针。但从程序员的角度来说，指令仅仅是从一端进入 CPU,从另一端退出，就像老的 8086 一样。

如果你仔细看过上面的内容，你会注意到上面提到过很重要的一个问题：如果执行指令的位置发生了跳转会发生什么?例如，当指令运行到“if”或者是“switch”时，会发生什么呢?在较老的处理器中这意味着清空流水线，等待新的跳转目的指令的取指执行。

当 CPU 指令队列中存储了超过 100 条指令时，发生流水线阻塞带来的性能损失是极其严重的。所有的指令都需要等待跳转目的的指令取回并且重启流水线。在这种情况下，乱序执行部件需要将跳转指令之后但是已经执行的微指令全部取消掉，返回到执行前的状态。当所有乱序执行的微指令都退出乱序执行部件之后，将它们丢弃掉，然后从新的地址开始执行。这对于处理器来说是相当困难的，而且发生的频率很高，因此对性能的影响很大。这时，引入了乱序执行部件的另外一个重要功能。

答案就是猜测执行。猜测执行意味着当遇到一个分支指令后，乱序执行部件会将所有分支的指令都执行一遍。一旦分支指令的跳转方向确定后，错误跳转方向的指令都将被丢弃。通过同时执行两个跳转方向的指令，避免了由于分支跳转导致的阻塞。处理器设计者还发明了分支预测缓存，当面临多个分支时进行预测，进一步提高了性能。虽然 CPU 阻塞仍然会发生，但是这个解决方案将 CPU 发生阻塞的概率降到了一个可以接受的范围。

最后，拥有超线程的处理器将两个虚拟的处理器暴露给共享的乱序执行部件。它们共享一个重排序缓存和乱序执行部件，让操作系统认为它们是两个独立的处理器，看上去就像这样：

超线程的处理器拥有两个虚拟的处理器，从而可以给乱序执行部件提供更多的数据。超线程对一般的应用程序都有性能提升，但是对一些计算密集型的应用，则会迅速使得乱序执行部件饱和。在这种情况下，超线程反而会略微降低性能。但这种情况毕竟是少数，超线程对于日常应用来讲通常都能够提供大约一倍的性能。

一个示例

这一切看上去有点令人感到困惑，那么我们举一个例子来让这一切变得清晰起来。

从应用程序的角度来看，我们仍然是运行在指令流水线上，就想老的 8086 处理器那样。处理器就是一个黑盒子。黑盒子会处理指令指针指向的指令，当处理完之后，会在内存里找到处理的结果。

但是从指令本身的角度来讲，这个过程可谓历经沧桑。我们下面介绍对于现今的处理器(大约在 2008-2013 年之间)，一条指令在其内部的过程。

首先，你是一条指令，你所属的程序正在运行。

你一直在耐心的等待指令指针会指向自己，等待被 CPU 运行。当指令指针距离你还有 4KB 远的时候(这大约是 1500 条指令)，你被 CPU 从内存取到指令缓存中。虽然从内存加载进入指令缓存需要一段时间，但是现在距离你被执行的时刻还很远，你有足够的时间。这个预取的过程属于流水线的第一级。

当指令指针离你越来越近，距离你还有 24 条指令的时候，你和你旁边的 5 个指令会被放到指令队列里面。

这个处理器有 4 个译码器，可以容纳一个复杂指令和最多三个简单指令。你碰巧是一条复杂指令，通过译码，你被翻译成 4 个微指令。

译码的过程可以划分为多步。译码过程中的一步是检查你需要的数据和猜测你可能会产生一个地址跳转。译码器一旦检测到需要的额外数据，不需要让你知道，这个数据就开始从内存加载到数据缓存中了。

你的四个微指令到达寄存器重命名表。你告诉它你需要读哪个内存地址(比如说 fs:[eax+18h])，然后寄存器重命名表将这个地址转换为临时地址供微指令使用。地址转化完成后，你的微指令将进入重排序缓存(Reorder Buffer, ROB)并记录指令次序。接着第一时间进入保留站(Reservation Station, RS)。

保留站用于存储已经准备就绪可以执行的指令。你的第三条微指令被立即选中并送往端口5,这个端口直接执行运算。但是你并不知道为什么它会被首先选中，无论如何，它确实被执行了。几个时钟周期之后你的第一条微指令前往端口2,该端口是读单元(Load Address地址 execution unit)。剩余的微指令一直等待，同时各个端口正在收集不同的微指令。他们都在等待端口 2 将数据从缓存和内存中加载进来并放在临时存储空间内。

他们等了很久……

相当久的时间……

不过在他们等待第一条微指令返回数据的时候，又有其他的新指令又进来。好在处理器知道如何让这些指令乱序执行(即后到达保留站的微指令被优先执行)。

当第一条微指令返回了数据，剩余的两条微指令被立即送往执行端口 0 和1.现在这 4 条微指令都已经运行，最终它们会返回保留站。

这些微指令返回后交出他们的“票”并给出各自的临时地址。通过这些地址，你作为一个完整的指令，将他们合并。最后 CPU 将结果交给你并使你退出

当你到达标有“退出”的门的时候，你会发现这里要排一个队列。你进入后发现你刚好站在你前面进来指令的后面，即使执行中的顺序可能已经不同，但你们退出的顺序继续保持一致。看来乱序执行部件真正知道自己做了什么。

每条指令最终离开 CPU,每次一条指令，就和指令指针指向的顺序一样!

结论

希望这篇小文能够给读者展示一些处理器工作的奥秘，要知道，这并不是魔术。

让我们回到最初的问题，现在我们应该可以给出一些较好的答案了。

处理器内部是如何工作的呢?在这个复杂的过程中，指令首先被分解为更小的微指令命令，这些微指令以乱序的方式尽可能快的被执行，然后按照原始的顺序提交执行结果。因此，从外部看来，所有的指令都是按照顺序的方式执行的。但是现在我们知道，处理器内部是以乱序的方式处理指令的，有时甚至以猜测的方式来运行分支代码。

运行一条指令究竟需要多长时间呢?对于没有使用流水线技术的处理器来说，这是一个容易回答的问题，但对于现代的处理器来说，一条指令的执行时间与它周围指令的内容以及临近 cache 的大小和内容都有关。一条指令通过处理器有一个最小的时间，但只能粗略的说这个时间是恒定的。一个好的程序员和编译器可以让很多条指令同时运行，从而使每条指令的分摊时间几乎为零。这里说的几乎为零的执行时间并不是指一条指令的总的执行时间很短，相反，通过整个乱序部件和等待内存读写数据是需要花费很多时间的。

一个新的处理器拥有 12 级或者 18 级、甚至更深的 31 级流水线意味着什么呢?这意味着更多的指令可以被同时送进加工厂。一个非常深的流水线可以让几百条指令同时被处理。当一切顺利时，一个乱序部件可以保持高速运转，从而获得惊人的吞吐量。不幸的是，深的流水线同时意味着流水线停顿会从一个相对可以容忍的性能损失变成一个可怕的性能噩梦。因为几百条指令都不得不停顿下来，等待流水线恢复运转。

我怎么根据这些信息来优化程序呢?幸运的是，CPU 可以在大部分常见情况下工作良好，并且编译器已经为乱序处理器优化了近 20 年。当指令和数据按照顺序(没有烦人的跳转)执行时，CPU 可以获得最好的性能。因此，首先，使用简单的代码。简单直接的代码会帮助编译器的优化引擎识别并优化代码。尽量不使用跳转指令，当你不得不跳转时，尽量每次跳转到同样的方向。复杂的设计，例如动态跳转表，虽然看起来很酷并且的确可以完成非常强大的功能，但不管是处理器还是编译器，都无法进行很好的预测处理，因此复杂的代码很可能导致流水线停顿和猜测错误，从而极大的损害处理器性能。其次，使用简单的数据结构。保持数据顺序、相邻和连续可以阻止数据停顿。使用正确的数据结构和数据分布可以获得很大的性能提升。只要保持代码和数据结构尽量简单，剩下的工作就可以放心地交给编译器的优化引擎来完成了。