Performance 机器代码生成、内存访问/寄存器操作模式和性能？

我真的很难为这个问题制定一个标题，我认为我做得不是很好，所以如果有人有更好的想法，编辑按钮是你的

考虑到在绝对最佳的情况下，内存操作会花费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在等待数据时，它可以执行其他代码，特别是考虑到大多数现代处理器出现故障，因此在最坏的情况下，最终，您将在获取数据上浪费同样的时间，但是拥有所有数据将允许代码片段更快地执行，从而使处理器暂停更短的时间。

CPU不切换线程，调度程序会切换线程

现代CPU不能严格按照顺序一次执行一条指令。它们执行推测性抓取，并提前准确地读取合并，以避免您所说的延迟

---

此外，在现代机器上，如果一次提取必须一直进行到RAM（称为“L2未命中”），则惩罚更像是200个周期。

我说的是L1访问。考虑到所有数据都在缓存线中。显然，在现实生活中，结果是不同的。如果所有数据都在缓存线中，那么在访问缓存线的任何部分时，都会提取整个缓存线。在许多RISC后端中，加载/存储分组是一种典型的优化。