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