为什么我可以不同于i + = 1性能 [英] Why can ++i ever be different from i+=1 performance-wise

问题描述

显然，在阅读旧标题

之后

为什么像这样的问题是++ i fster比i + = 1 甚至存在

问题是不有关人们提出问题的原因！这是为什么编译器会在 ++ i 和 i + = 1 之间产生差异，可能的情况下，这将是有意义的。虽然我很感激你所有的机智和深刻的意见，但我的问题不是这个。

---

好吧，让我试试以另一种方式提出问题，我希望我的英语是好的，我可以表达自己没有被误解这次，所以请阅读。让我们假设有人在一本10岁的书中读过这本书：

使用++ i over i = i +优点。

我不喜欢这个特定例子， / p>

很明显，当作者写这本书的时候，对他来说很有意义，他不只是把它写下来。我们知道现代编译器不在乎你是否使用 ++ i ， i + = 1 或 i = i + 1 ，代码将被优化，我们将有相同的asm输出。

这似乎很合乎逻辑：如果两个操作做同样的事情，并有相同的结果，没有理由编译 ++ i 合并成一个东西，并将 i + = 1 转换成另一个东西。

但自从图书作者写这本书后，他看到了差异！这意味着一些编译器实际上会为这两行生成不同的输出。这意味着编译器的人有一些理由来处理 ++ i 和 i + = 1 。 我的问题是为什么会这样做？

这只是因为很难/不可能使编译器高级到足以执行这样的优化那些天？或者在某些特定的平台/硬件上/在某些特殊情况下，在 ++ i 和 i + = 1 和这种类型的其他东西？或者也许它取决于变量类型？或者是编译器开发者只是懒惰？

解决方案

想象一个非优化编译器。它真的不在乎是否 ++ i 等价于 i + = 1 它可以想到的东西工作。它知道CPU具有用于相加的指令，并且它知道CPU具有增加整数的指令。因此假设 i 的类型为 int ，则 ++ i 它会发出类似于：

  inc< wherever_i_is> 
  

对于 i + = 1 例如：

 将常量1加载到寄存器
 add< wherever_i_is>到该寄存器
存储注册到< wherever_i_is> 
  

为了确定后面的代码应该与前者相同，注意到添加的常量是1，而不是2或1007.这需要编译器中的专用代码，标准不需要它，并且不是每个编译器总是这样做。

所以你的问题等于，为什么编译器会比我更倾向于我，因为我发现了这个等价，它没有？答案是现代编译器在很多时候比你更聪明，但并不总是这样，并不总是这样。

不一定。如果你看到一个关于什么是更快的声明，有时这本书的作者比你和编译器dumber。有时他很聪明，但他巧妙地在不再适用的条件下形成了自己的经验法则。有时他推测一个编译器的存在像我上面描述的一样，没有实际检查任何编译器，你曾经实际使用，是真的那么蠢。就像我刚才那样; - ）

Btw，10年前对于一个优秀的编译器来说太近了，不能进行优化。确切的时间刻度可能与你的问题不相关，但如果一个作者写这个，他们的借口是那是回到2002年，然后个人我不会接受它。这句话不是比现在更正确的。如果他们说1992年然后OK，个人我不知道什么编译器是那样，我不能矛盾他们。如果他们说1982，那么我仍然是可疑的（毕竟，C ++是发明的，然后它的大部分设计依赖于优化编译器，以避免在运行时大量的浪费工作，但我会授予，这个事实的最大用户是模板容器/算法，它在1982年不存在）。如果他们说1972年，我可能只是相信他们。当然有一个时期，C编译器是荣耀的装配者。

Apparently after reading the old title that was

Why do questions like is ++i fster than i+=1 even exist

people didn't bother to read the question itself thoroughly.

The question was not about people's reasons for asking that! It was about why would a compiler ever make a difference between ++i and i+=1, and are there any possible scenarios where that would make sense. While I appreciate all your witty and profound comments, my question was not about it.

---

Well, alright, let me try to put the question it in another way, I hope my English is good enough and I can express myself without being misunderstood this time, so please read it. Let's say someone read this in a 10-years-old book:

Using ++i over i=i+1 gives you a performance advantage.

I'm not keen on this particular example, rather talking more or less generally.

Obviously, when the author was writing the book, it made sense to him, he didn't just make it up. We know that modern compilers do not care about whether you use ++i, i+=1 or i = i + 1, the code will be optimized and we will have the same asm output.

This seems quite logical: if two operations do the same thing, and have the same result, there is no reason to compile ++i into one thing, and i+=1 into another thing.

But since the book author wrote it, he had seen the difference! It means that some compiler would actually produce different output for those two lines. It means that the guys that made the compiler had some reasons for treating ++i and i+=1 differently. My question is why would they ever do so?

Is it just because it was hard/impossible to make compilers advanced enough to perform such optimizations those days? Or maybe on some very specific platforms/hardware/in some special scenario it actually makes sense to make a difference between ++i and i+=1 and other stuff of that kind? Or maybe it depends on the variable type? Or were the compiler devs just lazy?

解决方案

Imagine a non-optimizing compiler. It really doesn't care whether ++i is equivalent to i+=1 or not, it just emits the first thing it can think of that works. It knows that the CPU has an instruction for addition, and it knows that the CPU has an instruction to increment an integer. So assuming i has type int, then for ++i it emits something like:

inc <wherever_i_is>

For i+=1, it emits something like:

load the constant 1 into a register
add <wherever_i_is> to that register
store that register to <wherever_i_is>

In order to determine that the latter code "should" be the same as the former, the compiler has to notice that the constant being added is 1, rather than 2 or 1007. That takes dedicated code in the compiler, the standard doesn't require it, and not every compiler has always done it.

So your question amounts to, "why would a compiler ever be dumber than me, since I've spotted this equivalence and it hasn't?". To which the answer is that modern compilers are smarter than you a lot of the time, but not always and it wasn't always the case.

since the book author wrote it, he had seen the difference

Not necessarily. If you see a pronouncement about what's "faster", sometimes the author of the book is dumber than both you and the compiler. Sometimes he's smart, but he cleverly formed his rules of thumb under conditions that no longer apply. Sometimes he has speculated about the existence of a compiler as dumb as the one I described above, without actually checking whether any compiler that you'd ever actually use, was really that dumb. Like I just did ;-)

Btw, 10 years ago is way too recent for a decent compiler with optimization enabled, to not make this particular optimization. The exact timescale probably isn't relevant to your question, but if an author wrote that and their excuse was "that was way back in 2002", then personally I wouldn't accept it. The statement wasn't any more correct then than it is now. If they said 1992 then OK, personally I don't know what compilers were like then, I couldn't contradict them. If they said 1982 then I'd still be suspicious (after all, C++ had been invented then. Much of its design relies on an optimizing compiler in order to avoid a hefty lot of wasteful work at runtime, but I'll grant that the biggest user of that fact is the template containers/algorithms, which didn't exist in 1982). If they said 1972, I'd probably just believe them. There certainly was a period in which C compilers were glorified assemblers.

这篇关于为什么我可以不同于i + = 1性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！