我很难为这个问题制定一个标题，而且我认为我做得不是很好，所以如果有人有更好的想法，编辑按钮就是你的了。
考虑到内存操作在绝对最佳情况下花费 3-4 个周期，甚至可能更多，并且读取比内存总线“更窄”的数据是次优的，当前生成的汇编语言结构不是次优的也？
寄存器操作花费的时间要少得多，所以为什么程序集不获取在表达式之前评估表达式所需的所有数据并快速执行它，从而减少线程切换并允许处理器执行其他线程。
get data 1 - 4 cycles
perform calculation 1 - 1 cycle
get data 2 - 4 cycles
perform calculation 2 - 1 cycle
get data 3 - 4 cycles
perform calculation 3 - 1 cycle
最后，有 15 个 CPU 使用周期。
get all data sequentially - 8 cycles
perform calculation 1 - 1 cycle
perform calculation 2 - 1 cycle
perform calculation 3 - 1 cycle
使用了 11 个周期，提高了 25%。此外，实际的 CPU 只忙了 3 个周期，因为内存由专用的片上硬件控制器获取，并且空闲时间更长。
我想 CPU 可以在等待第一个“示例”中的数据时安排其他代码执行，但是对于更短的窗口，并且切换上下文的周期惩罚几乎不值得，我认为第二个方法虽然更需要寄存器，但应该会带来更好的整体 CPU 性能。毕竟，现代处理器都至少有 16 个寄存器，即使是当前这一代新的移动设备 ARM 芯片也有 32 个寄存器。那为什么要这么保守呢？也许编译器还停留在 8 台寄存器机器的时代？
这个假设是否成立，或者当前的 CPU 架构可能不是为了受益于这种机制而设计的？我假设当 CPU 等待数据时，它可以执行其他代码，特别是考虑到大多数现代处理器都是无序的，所以最后，最坏的情况是，你会浪费同样的时间来获取数据，但是拥有所有数据将使代码片段执行得更快，从而使处理器停顿更短的时间。