if(a<901)是否比if(a<=900)快?

与这个简单示例中的情况不同,但循环复杂代码的性能略有变化。我想这需要对生成的机器代码进行一些处理,以防它是真的。


当前回答

假设我们讨论的是内部整数类型,不可能一个比另一个更快。它们显然在语义上是相同的。它们都要求编译器做完全相同的事情。只有一个严重损坏的编译器才能为其中一个生成劣质代码。

如果在某些平台上,对于简单整数类型,<比<=快,编译器应始终将常量的<=转换为<。任何没有这样做的编译器都将是一个糟糕的编译器(对于该平台)。

其他回答

对于浮点代码,甚至在现代体系结构上,<=比较可能确实会慢一些(一条指令)。这是第一个函数:

int compare_strict(double a, double b) { return a < b; }

在PowerPC上,首先执行浮点比较(更新条件寄存器cr),然后将条件寄存器移动到GPR,将“比较小于”位移位到位,然后返回。它需要四个指令。

现在考虑一下这个函数:

int compare_loose(double a, double b) { return a <= b; }

这需要与上面的compare_strict相同的工作,但现在有两个有趣的位:“小于”和“等于”。这需要一个额外的指令(cror-condition寄存器逐位OR)将这两个位组合为一。因此,compare_sloose需要五条指令,而compare_sstrict需要四条指令。

您可能认为编译器可以这样优化第二个函数:

int compare_loose(double a, double b) { return ! (a > b); }

然而,这将错误地处理NaN。NaN1<=NaN2和NaN1>NaN2都需要评估为假。

假设我们讨论的是内部整数类型,不可能一个比另一个更快。它们显然在语义上是相同的。它们都要求编译器做完全相同的事情。只有一个严重损坏的编译器才能为其中一个生成劣质代码。

如果在某些平台上,对于简单整数类型,<比<=快,编译器应始终将常量的<=转换为<。任何没有这样做的编译器都将是一个糟糕的编译器(对于该平台)。

仅当计算路径依赖于数据时:

a={1,1,1,1,1000,1,1,1,1}
while (i<=4)
{
     for(j from 0 to a[i]){ do_work(); }
     i++;
}

将计算250倍以上的时间(i<4)

真实世界的例子是计算曼德布洛特集合。如果包含一个迭代1000000次的像素,它将导致延迟,但与<=使用概率的重合度太低。

在C和C++中,编译器的一个重要规则是“仿佛”规则:如果执行X的行为与执行Y的行为完全相同,那么编译器可以自由选择使用哪一个。

在您的情况下,“a<901”和“a<=900”总是具有相同的结果,因此编译器可以自由编译任一版本。无论出于什么原因,如果一个版本更快,那么任何高质量的编译器都会为更快的版本生成代码。因此,除非您的编译器生成异常糟糕的代码,否则两个版本的运行速度将相等。

现在,如果你有一种情况,两位代码总是会产生相同的结果,但编译器很难证明,和/或编译器很难证实哪个版本更快,那么你可能会得到不同的代码以不同的速度运行。

PS如果处理器支持单字节常量(更快)和多字节常量(更慢),则原始示例可能以不同的速度运行,因此与255(1字节)进行比较可能比与256(2字节)进行对比更快。我希望编译器做任何更快的事情。

即使有差异,你也不应该注意到。此外,在实践中,除非你要使用一些神奇的常数,否则你必须做一个额外的a+1或a-1来使条件成立,这无论如何都是一个非常糟糕的实践。