几天前在Facebook上发表演讲 - slides，video，Andrei Alexandrescu谈到可能证明我们错了的共同直觉。对我来说，幻灯片7中出现了一个非常有趣的观点，他指出假设“更少的指令=更快的代码”是不正确的，更多的指令并不一定意味着更慢的代码。
我的问题出现了：他的谈话的音质（大约6：20分钟）并不是那么好，我不太了解这个解释，但从我得到的是他将退役指令与最优指数进行比较性能水平的算法。
然而，根据我的理解，这是不可能做到的，因为这是两个独立的结构层面。说明（特别是实际上已退役的说明）是一项非常重要的措施，基本上可以让您了解实现目标的绩效。如果我们省略指令的延迟，我们可以推断出更少的退出指令=更快的代码。现在，当然有些情况下，在循环内执行复杂计算的算法即使在循环内执行也会产生更好的性能，因为它会更早地破坏循环（想想图遍历）。但是，在复杂程度上比较算法而不是说这个循环有更多的指令而且比另一个更好会不会更有用？从我的观点来看，更好的算法最终会有更少的退役指令。
有人可以帮助我了解他的例子，以及如何（显着）更多退休指令可以带来更好的表现吗？
答案 0 :(得分：20)
质量确实很差，但我认为他导致CPU有利于计算，但遭受内存搜索性能不佳（RAM比CPU慢得多）和分支（因为CPU作为管道工作） ，分支可能导致管道中断。）
在某些情况下，更多指令更快：
Branch prediction - 即使我们需要做更多的指令，但它会导致更好的分支预测，CPU的流水线将会有更多的时间，更少的操作会被“抛弃”它最终会带来更好的表现。例如，This thread显示了如何做同样的事情，但首先排序 - 提高了执行力。
CPU Cache - 如果您的代码更优化缓存，并遵循principle of locality - 它更可能比没有代码的代码更快，即使代码不是做一半的指令。 This thread给出了一个小缓存优化的示例 - 如果没有缓存优化，相同数量的指令可能会导致代码速度变慢。
完成哪些指令也很重要。有时 - 某些指令可能比其他指令更慢，例如 - 除法可能比整数加法慢。
注意：以上所有内容都取决于机器，如果/它们实际上如何改变性能可能因架构而异。
答案 1 :(得分：6)
指令的数量本身并不是一个好的措施。
更少的退役指令（因为没有其他事情可做）=更快的代码。
更少的退役指令（因为他们必须等待依赖关系）=代码更慢。
有时，代码中的更多指令也意味着更多的退出指令，因为它们可能会耗尽执行槽，否则会浪费在案例2中。