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
其他回答
不，它在大多数架构上不会更快。您没有指定，但在x86上，所有的积分比较通常将在两个机器指令中实现：
测试或cmp指令，用于设置EFLAGS以及Jcc（跳转）指令，具体取决于比较类型（和代码布局）：jne-如果不等于-->ZF=0，则跳转jz-如果零（等于）-->ZF=1则跳转jg-如果大于-->ZF=0且SF=OF，则跳转（等等）
示例（为简洁起见编辑）使用$gcc-m32-S-masm=inteltest.c编译
if (a < b) {
// Do something 1
}
编译到：
mov eax, DWORD PTR [esp+24] ; a
cmp eax, DWORD PTR [esp+28] ; b
jge .L2 ; jump if a is >= b
; Do something 1
.L2:
And
if (a <= b) {
// Do something 2
}
编译到：
mov eax, DWORD PTR [esp+24] ; a
cmp eax, DWORD PTR [esp+28] ; b
jg .L5 ; jump if a is > b
; Do something 2
.L5:
因此，两者之间的唯一区别是jg与jge指令。这两者将花费相同的时间。
我想指出的是，没有任何东西表明不同的跳转指令需要相同的时间。这个问题回答起来有点棘手，但我可以给出以下答案：在“英特尔指令集参考”中，它们都被分组在一条公共指令Jcc（如果满足条件则跳转）下。根据附录C中的《优化参考手册》进行了相同的分组。延迟和吞吐量。
Latency—执行核心，以完成形成的所有μ操作的执行指令。
吞吐量—需要的时钟周期数等待发出端口可以接受相同的指令再一次对于许多指令，指令的吞吐量可以是显著低于其延迟
Jcc的值为：
Latency Throughput
Jcc N/A 0.5
Jcc上有以下脚注：
条件跳转指令的选择应基于第3.4.1节“分支预测优化”的建议，以提高分支的可预测性。当成功预测分支时，jcc的延迟实际上为零。
因此，在英特尔文档中，对一条Jcc指令的处理方式与其他指令没有任何区别。
如果考虑用于实现指令的实际电路，可以假设EFLAGS中的不同位上有简单的“与/或”门，以确定是否满足条件。因此，没有理由让一条测试两个位的指令比只测试一个位花费更多或更少的时间（忽略比时钟周期短得多的门传播延迟）
编辑：浮点
x87浮点也是如此：（与上面的代码几乎相同，但使用double而不是int。）
fld QWORD PTR [esp+32]
fld QWORD PTR [esp+40]
fucomip st, st(1) ; Compare ST(0) and ST(1), and set CF, PF, ZF in EFLAGS
fstp st(0)
seta al ; Set al if above (CF=0 and ZF=0).
test al, al
je .L2
; Do something 1
.L2:
fld QWORD PTR [esp+32]
fld QWORD PTR [esp+40]
fucomip st, st(1) ; (same thing as above)
fstp st(0)
setae al ; Set al if above or equal (CF=0).
test al, al
je .L5
; Do something 2
.L5:
leave
ret
在C和C++中，编译器的一个重要规则是“仿佛”规则：如果执行X的行为与执行Y的行为完全相同，那么编译器可以自由选择使用哪一个。
在您的情况下，“a<901”和“a<=900”总是具有相同的结果，因此编译器可以自由编译任一版本。无论出于什么原因，如果一个版本更快，那么任何高质量的编译器都会为更快的版本生成代码。因此，除非您的编译器生成异常糟糕的代码，否则两个版本的运行速度将相等。
现在，如果你有一种情况，两位代码总是会产生相同的结果，但编译器很难证明，和/或编译器很难证实哪个版本更快，那么你可能会得到不同的代码以不同的速度运行。
PS如果处理器支持单字节常量（更快）和多字节常量（更慢），则原始示例可能以不同的速度运行，因此与255（1字节）进行比较可能比与256（2字节）进行对比更快。我希望编译器做任何更快的事情。
仅当计算路径依赖于数据时：
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编译到的底层架构。某些处理器和架构可能具有等于或小于等于的显式指令，这些指令以不同的周期执行。
但这很不寻常，因为编译器可以绕过它，使它变得无关紧要。
我认为两者都不快。编译器在每个条件下生成具有不同值的相同机器代码。
if(a < 901)
cmpl $900, -4(%rbp)
jg .L2
if(a <=901)
cmpl $901, -4(%rbp)
jg .L3
我的示例if来自Linux上x86_64平台上的GCC。
编译器编写者是非常聪明的人，他们认为这些事情以及我们大多数人认为理所当然的其他事情。
我注意到，如果它不是常数，那么在这两种情况下都会生成相同的机器代码。
int b;
if(a < b)
cmpl -4(%rbp), %eax
jge .L2
if(a <=b)
cmpl -4(%rbp), %eax
jg .L3
