CPU乱序执行,有两条指令流水线的cpu

　　假设工人执行每个步骤需要一个月的时间。如果不采用流水线，而是采用串联法，一年可以组装六辆车。流程见下图：

　　连载的效率太有限了。根本原因是组装的两步都是一个人完成的。如果有人能在装配进行的同时制造零件，那么效率会大大提高，也就是每个工序只专注一件事，我们再带一个工人进来。

　　这样一个人负责制造零件，另一个人负责组装零件。这两个作业重叠，流程如下图所示：

　　增加一个人后，除了第一个月，每个月都有一个完整的制件和组装的过程，所以一年可以完成11辆车的组装(比串联模式下的6辆车几乎翻了一倍)，从第二年开始，每年可以组装12辆车(直接翻了一倍)。

　　这个过程就是流水线的执行过程，因为我们把汽车制造过程分为两步，所以上面的流水线就成了第二条流水线。

　　我们继续优化。我们将制造零件的步骤分为时间周期较短的冲压和焊接，将装配步骤分为时间周期较短的喷漆和总装，并假设每一步的时间周期为0.5个月。

　　当然，我们得多雇两个人。

　　现在是四级流水线。神奇的事情发生了。四级流水线让原本需要一年的任务现在只需要4.5个月就能完成，效率再次提升。如下图所示：

　　2.2.现代CPU的流水线现代CPU支持多级指令流水线。比如支持同时取指令-指令解码-指令执行-内存访问-数据回写的处理器，可以称为五级指令流水线。

　　此时，CPU可以在一个时钟周期内同时运行五个不同阶段的指令，其中每个阶段占用一个或多个指令周期(CPU占用的执行时间最长)。从本质上来说，流水线技术并不能缩短单个指令的执行时间，而是变相提高了指令的吞吐量。

　　上面的CPU流水线图并不是一个特定类型CPU的例子，而是特意画成这样来说明几个问题。

　　一般来说，CPU设计者会选择执行时间最长的流水线阶段作为一个时钟周期，以保证其他阶段能在一个时钟周期内完成，避免流水线中断。每个流水线阶段的时间是一个时钟周期，但是实际操作时间可能短于一个时钟周期。例如，解码器实际上是一个组合逻辑电路。由于门延迟低，它不需要一个完整的时钟周期来完成自己的任务。任务完成后，CPU其实是在“等待”的。很多人可能会问，既然流水线这么好用，为什么CPU设计师不设计一条超长流水线呢？这就需要解释超长流水线的瓶颈了。

　　3.超长管道3.1的瓶颈。性能瓶颈流水线长度的增加有性能代价。

　　每个流水线级的输出都需要放在流水线寄存器中，然后在下一个时钟周期，交给下一个流水线级处理。对于每个流水线，需要多一个写入流水线寄存器的阶段。

　　以多线程为例，适当数量的多线程会提高数据处理速度，但当线程数量过大时，线程间切换的时间成本就不容忽视，线程的增加甚至可能成为性能提升的负担。

　　3.2.功耗瓶颈增加了流水线的深度，需要同步提高CPU的主频。再看这张照片：

　　因为流水线的每一级都被分成非常精细的部分，甚至其中的一些部分并没有完全占据单个时钟周期，这意味着在单个时钟周期内可以完成的事情更少。所以只有提高主频，CPU才能在指令响应时间这个指标上保持和以前一样的性能。

　　增加主频和流水线深度意味着晶体管增加，意味着功耗变大。

　　没有人想拥有一台充电3小时工作20分钟的笔记本电脑。

　　3.3.以上图为例(我不会再贴了)。指令1的存储器访问操作使用了多个时钟周期，导致指令2和指令3在指令1之前完成。

　　如果是一般代码没问题，但是如果是有依赖关系的代码，比如：

　　浮点a=3.14159 * 0.2//指令1

　　float b=a * 2；//指令2

　　float c=B1；//指令3

　　浮点d=10//指令4指令1、指令2、指令3的执行顺序绝不能出现如图所示的乱序。有两点需要我们注意：

　　因为上图的情况，CPU确实有可能乱序执行；CPU需要防止有依赖关系的指令乱序执行(指令1，2，3)，转而让后面没有依赖关系的指令(指令4)先执行。对于第2条，如果流水线只有五个阶段，很容易说CPU自然有办法判断哪些指令有依赖关系，拒绝指令乱序。但是如果有20条流水线，CPU肯定还是有办法判断的，但是可以想象这种判断必然会影响CPU的性能。

　　回到本文开头提到的编译器指令重排序，当然包括Java在内的JIT把字节码编译成机器码时的指令重排序就是把没有依赖关系的指令放在一起，本质上是为了适应CPU，充分发挥CPU流水线的功能，从而提高性能。

　　4.总结说了这么多，很有可能在我后续的文章中一句话就提到了。

　　其实我想表达的想法是，实际代码运行顺序可能与代码编写顺序不一致。这句话很容易记住，但也许总会有人和我一样，想更深入一点去理解这句话的精髓。

　　除了本文所描述的，在CPU和cache的交互过程中，硬件工程师确实给软件开发者挖了很多坑，内存壁垒就是在这种背景下产生的。

相关文章阅读