optimization - 基本操作 cpu 时间成本

Question

我想知道如何优化资源非常有限的系统的循环。假设我们有一个基本的 for 循环，例如(用 javascript 编写):

<小时/>

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

<小时/>

我真的不知道，!= 不是比 > 便宜吗？

如果有任何涵盖基本运算符上下文中的计算成本的资源，我将不胜感激，例如前面提到的>>、~、! ，等等。

Answer 1

现代 CPU 上的性能绝非微不足道。以下是一些使事情变得复杂的事情:

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

所以简短的答案是“不要试图智胜编译器”。如果您能够在两个等效表达式之间进行选择，编译器可能也能够执行相同的操作，并且会选择最有效的一个。指导费用会有所不同，具体取决于上述所有因素。正在执行哪些其他指令、CPU 缓存中有哪些数据、代码运行在哪个精确的 CPU 模型上，等等。在一种情况下非常高效的代码在其他情况下可能非常低效。编译器将尝试选择最普遍有效的指令，并尽可能地调度它们。除非您比编译器更了解这一点，否则您不太可能做得更好。

除非您真的知道自己在做什么，否则不要尝试此类微优化。如上所示，低级性能是一个极其复杂的主题，并且很容易编写导致代码速度慢得多的“优化”。或者只是牺牲了一些根本没有区别的可读性。

此外，您的大部分代码根本不会对性能产生可衡量的影响。人们通常喜欢在这个主题上引用(或错误引用)Knuth:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

人们经常将此解释为“不必费心去优化你的代码”。如果您真正阅读了完整的引文，一些更有趣的结果应该会变得清晰:

大多数时候，我们应该忘记微优化。大多数代码很少被执行，因此优化并不重要。请记住 CPU 每秒可以执行的指令数，很明显，必须非常频繁地执行代码块才能使其优化产生任何效果。所以大约 97% 的时候，你的优化都是浪费时间。但他也表示，有时(3% 的时间)，您的优化会很重要。显然，寻找这 3% 有点像大海捞针。如果您只是决定总体上“优化您的代码”，那么您将在前 97% 上浪费时间。相反，您需要首先找到真正需要优化的 3%。换句话说，通过分析器运行您的代码，并让它告诉您哪些代码占用了最多的 CPU 时间。然后你就知道要优化哪里了。这样您的优化就不再为时过早。