if(a<901)是否比if(a<=900)快?
与这个简单示例中的情况不同,但循环复杂代码的性能略有变化。我想这需要对生成的机器代码进行一些处理,以防它是真的。
if(a<901)是否比if(a<=900)快?
与这个简单示例中的情况不同,但循环复杂代码的性能略有变化。我想这需要对生成的机器代码进行一些处理,以防它是真的。
当前回答
只有当制造计算机的人不擅长布尔逻辑的时候。他们不应该这样。
每个比较(>=<=><)都可以以相同的速度进行。
每一次比较都只是一次减法(差值),看看它是正还是负。(如果设置了msb,则数字为负数)
如何检查a>=b?Sub a-b>=0检查a-b是否为正。如何检查a<=b?Sub 0<=b-a检查b-a是否为正。如何检查a<b?Sub a-b<0检查a-b是否为负。如何检查a>b?Sub 0>b-a检查b-a是否为负。
简单地说,对于给定的操作,计算机可以在引擎盖下面执行以下操作:
a>=b==msb(a-b)==0a<=b==msb(b-a)==0a>b==msb(b-a)==1a<b==msb(a-b)==1
当然,计算机实际上也不需要执行==0或==1。对于==0,它可以将电路中的msb反相。
无论如何,他们肯定不会将a>=b计算为a>b||a==b lol
其他回答
至少,如果这是真的,编译器可以轻松地优化a<=b到!(a>b),因此,即使比较本身实际上较慢,但除了最简单的编译器之外,您也不会注意到差异。
TL;DR答案
对于架构、编译器和语言的大多数组合,<不会比<=快。
完整答案
其他答案都集中在x86架构上,我不太了解ARM架构(您的示例汇编程序似乎是这样),无法对生成的代码进行具体评论,但这是一个非常特定于架构的微优化示例,很可能是反优化,也可能是优化。
因此,我认为这种微优化是货物崇拜编程的一个例子,而不是最佳软件工程实践。
反例
可能有一些架构是优化的,但我知道至少有一种架构可能是相反的。古老的Transputer体系结构只有等于和大于或等于的机器代码指令,因此所有比较都必须从这些原语构建。
即使如此,在几乎所有的情况下,编译器都可以以这样的方式对求值指令进行排序,即在实践中,没有任何比较比任何其他比较都有任何优势。但最坏的情况是,它可能需要添加反向指令(REV)来交换操作数堆栈上的前两项。这是一个单字节指令,它需要一个周期才能运行,因此开销最小。
总结
像这样的微优化是优化还是反优化取决于您正在使用的特定架构,因此养成使用特定架构的微优化的习惯通常是一个坏主意,否则您可能会在不合适时本能地使用微优化,看起来这正是您正在阅读的书所倡导的。
它们的速度相同。也许在某些特殊的架构中,他/她所说的是对的,但在x86家族中,至少我知道他们是一样的。因为为此,CPU将执行一个减法(a-b),然后检查标志寄存器的标志。该寄存器的两位被称为ZF(零标志)和SF(符号标志),它在一个周期内完成,因为它将通过一个掩码操作完成。
在C和C++中,编译器的一个重要规则是“仿佛”规则:如果执行X的行为与执行Y的行为完全相同,那么编译器可以自由选择使用哪一个。
在您的情况下,“a<901”和“a<=900”总是具有相同的结果,因此编译器可以自由编译任一版本。无论出于什么原因,如果一个版本更快,那么任何高质量的编译器都会为更快的版本生成代码。因此,除非您的编译器生成异常糟糕的代码,否则两个版本的运行速度将相等。
现在,如果你有一种情况,两位代码总是会产生相同的结果,但编译器很难证明,和/或编译器很难证实哪个版本更快,那么你可能会得到不同的代码以不同的速度运行。
PS如果处理器支持单字节常量(更快)和多字节常量(更慢),则原始示例可能以不同的速度运行,因此与255(1字节)进行比较可能比与256(2字节)进行对比更快。我希望编译器做任何更快的事情。
您可以说这行在大多数脚本语言中都是正确的,因为额外的字符会导致代码处理稍慢。然而,正如上面的答案所指出的,它在C++中应该没有任何影响,而使用脚本语言所做的任何事情都可能不太关心优化。