基本操作cpu时间成本

Question

我想知道如何为资源非常有限的系统优化循环.比方说,如果我们有一个基本for循环,就像(写入javascript):

---

for(var i = someArr.length - 1; i > -1; i--) { someArr[i] }

---

我老实说不知道,是不是!=比便宜>？

我将覆盖计算成本基础运营的背景下,像前述的任何资源感激>>,~,!,等等.

Answer 1

在现代CPU上的性能远非微不足道.以下是一些使其复杂化的事情:

• 电脑很快.您的CPU每秒可执行超过60亿条指令.因此,即使是最慢的指令也可以每秒执行数百万次,这意味着只有经常使用它才真正重要
• 现代CPU同时有数百条指令在飞行中.它们是流水线的,这意味着在读取一条指令时,另一条指令从寄存器读取,第三条指令正在执行,第四条指令正在写入寄存器.现代CPU有15-20个这样的阶段.除此之外,他们可以在每个阶段同时执行3-4条指令.他们可以重新排序这些说明.如果乘法单元正被另一条指令使用,那么我们也许可以找到一个例如执行的加法指令.因此,即使您混入了一些缓慢的指令,通过在等待慢速指令完成时执行其他指令,可以在大多数情况下很好地隐藏它们的成本.
• 内存比CPU慢几百倍.如果通过从内存中检索数据使其成本相形见绌,那么正在执行的指令并不重要.甚至这也不可靠,因为CPU有自己的板载缓存来试图隐藏这个成本.

所以简短的回答是"不要试图超越编译器".如果您能够在两个等效表达式之间进行选择,则编译器可能会执行相同的操作,并将选择最有效的表达式.根据所有上述因素,指令的成本会有所不同.执行哪些其他指令,CPU缓存中有哪些数据,运行代码的精确CPU模型等等.在一种情况下超高效的代码在其他情况下可能效率非常低.编译器将尝试选择最普遍有效的指令,并尽可能安排它们.除非你比编译器了解更多,否则你不太可能做得更好.

除非你真的知道自己在做什么,否则不要尝试这种微观优化.如上所示,低级性能是一个非常复杂的主题,并且很容易编写导致代码速度慢得多的 "优化" .或者只是牺牲对可以完全没有区别的东西的可读性.

此外,您的大多数代码根本不会对性能产生可测量的影响.人们通常喜欢在这个问题上引用(或错误引用)Knuth:

我们应该忘记小的效率,大约97%的时间说:过早的优化是所有邪恶的根源

人们经常将此解释为"不要试图优化代码".如果您确实阅读了完整的引用,一些更有趣的后果应该变得清晰:

大多数时候,我们应该忘记微观优化.大多数代码执行得很少,优化无关紧要.牢记的一个CPU能够每秒执行的指令数,很明显,一个代码块具有要执行非常经常用于优化在它有任何影响.因此,大约97%的时间,您的优化将浪费时间.但他也说有时(3%的时间),你的优化会很重要.显然,寻找那些3%有点像在大海捞针.如果您只是决定"优化代码",那么您将浪费时间在前97%.相反,您需要首先找到实际需要优化的3%.换句话说,通过分析器运行代码,让它告诉你哪个代码占用了最多的CPU时间.然后你知道在哪里优化.然后你的优化不再为时过早.

Answer 2

除了最极端(实时嵌入式系统？)环境之外,这种微优化在任何情况下都会对您的代码产生显着差异的可能性极小.如果担心让代码可读和可维护,那么你的时间可能会更好.

如有疑问,请先问唐纳德克努特:

http://shreevatsa.wordpress.com/2008/05/16/premature-optimization-is-the-root-of-all-evil/

或者,对于微优化的略微不那么高的看法:

http://www.codinghorror.com/blog/archives/000185.html