几天前，在 Facebook 的演讲中——幻灯片、视频，Andrei Alexandrescu 谈到了可能证明我们错了的常见直觉。对我来说，幻灯片 7 上出现了一个非常有趣的观点，他指出“更少的指令 = 更快的代码”的假设是不正确的，更多的指令不一定意味着更慢的代码。
我的问题来了：他的演讲（大约 6 分 20 秒）的音频质量不太好，我不太理解解释，但据我所知，他正在将退休指令与算法的最优性进行比较一个性能水平。
但是，据我了解，这是无法做到的，因为这是两个独立的结构级别。指令（尤其是实际停用的指令）是一项非常重要的衡量标准，基本上，它可以让您了解实现目标的性能。如果我们忽略一条指令的延迟，我们可以概括出更少的退役指令 = 更快的代码。当然，在某些情况下，即使在循环内执行复杂计算的算法也会产生更好的性能，因为它会更早地中断循环（想想图遍历）。但是，在复杂性级别上与算法进行比较，而不是说这个循环有更多指令并且比另一个更好，难道不是更有用吗？从我的角度来看，
有人可以帮助我了解他的示例将走向何方，以及如何（显着）更多退休指令导致更好的性能？
质量确实很差，但我认为他导致了这样一个事实，即 CPU 对计算有好处，但在内存寻道（RAM 比 CPU 慢得多）和分支（因为 CPU 用作管道和分支）方面表现不佳可能导致管道破裂）。
以下是更多指令更快的一些情况：
分支预测- 即使我们需要执行更多指令，但它会导致更好的分支预测，CPU 的管道将有更多时间充满，并且会“抛出”更少的操作，最终导致更好的性能. 例如，这个线程显示了如何做同样的事情，但首先排序 - 提高性能。
CPU 缓存- 如果您的代码对缓存进行了更多优化，并遵循局部性原则- 它更有可能比没有的代码更快，即使代码没有执行一半的指令。这个线程给出了一个小缓存优化的例子——如果没有缓存优化，相同数量的指令可能会导致代码慢得多。
执行哪些指令也很重要。有时 - 某些指令的执行速度可能比其他指令慢，例如 -除法可能比整数加法慢。
注意：以上所有内容都取决于机器，并且它们如何/是否实际改变性能可能因一种架构而异。
指令数量本身并不是一个好的衡量标准。
更少的退役指令（因为没有更多的事情要做）=更快的代码。
更少的退役指令（因为它们必须等待依赖）= 更慢的代码。
有时，代码中的更多指令也意味着更多的退役指令，因为它们可能会用完在情况 2 中会被浪费的执行槽。