if（a<901）是否比if（a<=900）快？
与这个简单示例中的情况不同，但循环复杂代码的性能略有变化。我想这需要对生成的机器代码进行一些处理，以防它是真的。
当前回答
不，它在大多数架构上不会更快。您没有指定，但在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
其他回答
即使有差异，你也不应该注意到。此外，在实践中，除非你要使用一些神奇的常数，否则你必须做一个额外的a+1或a-1来使条件成立，这无论如何都是一个非常糟糕的实践。
TL；DR答案
对于架构、编译器和语言的大多数组合，<不会比<=快。
完整答案
其他答案都集中在x86架构上，我不太了解ARM架构（您的示例汇编程序似乎是这样），无法对生成的代码进行具体评论，但这是一个非常特定于架构的微优化示例，很可能是反优化，也可能是优化。
因此，我认为这种微优化是货物崇拜编程的一个例子，而不是最佳软件工程实践。
反例
可能有一些架构是优化的，但我知道至少有一种架构可能是相反的。古老的Transputer体系结构只有等于和大于或等于的机器代码指令，因此所有比较都必须从这些原语构建。
即使如此，在几乎所有的情况下，编译器都可以以这样的方式对求值指令进行排序，即在实践中，没有任何比较比任何其他比较都有任何优势。但最坏的情况是，它可能需要添加反向指令（REV）来交换操作数堆栈上的前两项。这是一个单字节指令，它需要一个周期才能运行，因此开销最小。
总结
像这样的微优化是优化还是反优化取决于您正在使用的特定架构，因此养成使用特定架构的微优化的习惯通常是一个坏主意，否则您可能会在不合适时本能地使用微优化，看起来这正是您正在阅读的书所倡导的。
不，它在大多数架构上不会更快。您没有指定，但在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++中应该没有任何影响，而使用脚本语言所做的任何事情都可能不太关心优化。
至少，如果这是真的，编译器可以轻松地优化a<=b到！（a>b），因此，即使比较本身实际上较慢，但除了最简单的编译器之外，您也不会注意到差异。
