依赖的前后增量内存访问的性能

Question

我的问题主要适用于firestorm/icestorm (因为这是我拥有的硬件)，但我很好奇其他有代表性的arm内核也会做什么。Arm有奇怪的前后递增寻址模式。如果我有(例如)来自同一个寄存器的两个后增量负载，那么第二个负载是否依赖于第一个寄存器，或者CPU是否足够聪明地并行执行它们？

Answer 1

M1执行单元的确切行为是，主要是无文档的。不过，在这种情况下肯定存在一个依赖链。事实上，很难打破它，而现代处理器的设计使它变得更加困难:解码器、执行单元、调度器都是不同的单元，根据执行单元并行执行的指令动态调整调度将是疯狂的，以便能够在这种特殊情况下打破链。更不用说指令是流水线的，通常需要很少的周期才能提交。此外，指令的时间是可变的，根据获取的内存位置。最后，即使是这种情况，火灾文档也没有提到这样的反馈循环(参见下面的链接)。处理器优化这种模式的另一种可能的解决方案是将微指令融合起来，以便合并增量并添加更多的并行性，但对于相对较小的改进来说，这是相当复杂的，而且到目前为止还没有证据表明火风暴可以做到这一点(有关火暴指令融合/消除的更多信息，请参见这里 )。

M1的大内核(苹果的火爆)被设计成大规模并行。他们每个核心都有6个ALU，因此它们可以在每个核心上并行执行大量指令(可能以牺牲更高的延迟为代价)。然而，这种设计往往需要比目前主流的x86英特尔/AMD替代(奥尔德莱克/XX-海湾架构搁置)更多的晶体管。因此，核心工作在一个显着的低频，以保持低能耗。这意味着，与其他体系结构相比，依赖链在这种体系结构上的开销要大得多，除非有足够的独立指令可以在关键路径上并行执行。有关CPU工作方式的更多信息，请线程现代微处理器-90分钟指南！。有关M1处理器的更多信息，尤其是火暴体系结构，请阅读这种深刻的分析。

请注意，Icestorm内核的设计是为了节省能源，因此它们的并行性要小得多，因此在这样的核心上，拥有依赖链应该不那么关键。尽管如此，减少依赖往往是个好主意。

至于其他ARM处理器，最近的核心架构并不像火风暴那样并行。例如，皮质-A77和Neoverse V1只有4个ALU(这已经相当不错)。还需要关注在给定代码中实际使用的每条指令的延迟。这些信息可以在ARM网站上找到，AFAIK还没有发布给苹果处理器(需要对指令进行基准测试)。

至于前后增量，我预计它们会占用相同的时间(同样的延迟和吞吐量)，特别是在大内核上，如Firestorm (试图以牺牲更多的晶体管为代价来减少最频繁指令的延迟)。但是，对于给定代码的指令的实际调度可能导致一个比另一个慢，如果延迟没有被其他指令隐藏。

Answer 2

我在IRC上得到了这样的回答:这种使用将相当快(当您认为它对应于典型的循环模式时，这是有意义的；如果循环携带的依赖关系没有太大的伤害，那么很好)，但是如果可能的话，还是最好避免它，因为它占用了重命名的带宽。