< 比 <= 快吗？

不，在大多数架构上它不会更快。您没有指定，但在 x86 上，所有积分比较通常都将在两条机器指令中实现：

设置 EFLAGS 的测试或 cmp 指令

还有一条 Jcc（跳转）指令，具体取决于比较类型（和代码布局）：

jne - 如果不相等则跳转 --> ZF = 0

jz - 如果为零（等于）则跳转 --> ZF = 1

jg - 如果大于则跳转 --> ZF = 0 且 SF = OF

（ETC...）

示例（为简洁而编辑）使用 $ gcc -m32 -S -masm=intel test.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:

和

    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 指令。两者将花费相同的时间。

我想解决没有任何迹象表明不同的跳转指令需要相同的时间的评论。这个问题有点难以回答，但我可以给出以下几点：在 Intel Instruction Set Reference 中，它们都被组合在一个共同的指令 Jcc 下（如果满足条件则跳转）。在附录 C. 延迟和吞吐量中的 Optimization Reference Manual 下进行了相同的分组。

延迟 — 执行内核完成构成指令的所有微指令的执行所需的时钟周期数。

吞吐量——在发布端口可以再次自由地接受相同指令之前需要等待的时钟周期数。对于许多指令，一条指令的吞吐量可能远低于其延迟

Jcc 的值为：

      Latency   Throughput
Jcc     N/A        0.5

在 Jcc 上有以下脚注：

条件跳转指令的选择应基于第 3.4.1 节“分支预测优化”的建议，以提高分支的可预测性。当分支预测成功时，jcc 的延迟实际上为零。

因此，英特尔文档中的任何内容都不会将一条 Jcc 指令与其他指令区别对待。

如果考虑用于实现指令的实际电路，可以假设在 EFLAGS 的不同位上会有简单的 AND/OR 门，以确定是否满足条件。因此，一条指令测试两位的时间没有理由比一条只测试一位的指令花费更多或更少的时间（忽略门传播延迟，它远小于时钟周期。）

编辑：浮点

这也适用于 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

从历史上看（我们谈论的是 1980 年代和 1990 年代初期），有一些架构确实如此。根本问题是整数比较本质上是通过整数减法实现的。这导致了以下情况。

Comparison     Subtraction
----------     -----------
A < B      --> A - B < 0
A = B      --> A - B = 0
A > B      --> A - B > 0

现在，当 A < B 减法必须借一个高位以使减法正确时，就像手动加减时进位和借位一样。这个“借来的”位通常被称为进位位，并且可以通过分支指令进行测试。如果减法相同为零（这意味着相等），则将设置称为 零位 的第二位。

通常至少有两条条件分支指令，一条在进位位上分支，一条在零位上。

现在，为了了解问题的核心，让我们扩展上表以包括进位和零位结果。

Comparison     Subtraction  Carry Bit  Zero Bit
----------     -----------  ---------  --------
A < B      --> A - B < 0    0          0
A = B      --> A - B = 0    1          1
A > B      --> A - B > 0    1          0

因此，可以在一条指令中实现 A < B 的分支，因为在这种情况下，进位位是 only 清零的，也就是说，

;; Implementation of "if (A < B) goto address;"
cmp  A, B          ;; compare A to B
bcz  address       ;; Branch if Carry is Zero to the new address

但是，如果我们想要进行小于或等于比较，我们需要对零标志进行额外检查以捕捉相等的情况。

;; Implementation of "if (A <= B) goto address;"
cmp A, B           ;; compare A to B
bcz address        ;; branch if A < B
bzs address        ;; also, Branch if the Zero bit is Set

因此，在某些机器上，使用“小于”比较可能会节省一条机器指令。这在亚兆赫处理器速度和 1:1 CPU 与内存速度比的时代是相关的，但在今天几乎完全无关紧要。

假设我们谈论的是内部整数类型，那么一种方法不可能比另一种更快。它们显然在语义上是相同的。他们都要求编译器做同样的事情。只有严重损坏的编译器会为其中之一生成劣质代码。

如果在某些平台上，对于简单的整数类型，< 比 <= 快，那么编译器应该总是将 <= 转换为 < 以获得常量。任何没有的编译器都只是一个糟糕的编译器（对于那个平台）。

我看到两者都不是更快。编译器在每个条件下生成具有不同值的相同机器代码。

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

对于浮点代码，即使在现代架构上， <= 比较也可能确实更慢（通过一条指令）。这是第一个功能：

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 - 条件寄存器按位或）将这两位合并为一个。所以 compare_loose 需要五个指令，而 compare_strict 需要四个。

你可能认为编译器可以像这样优化第二个函数：

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

但是，这将错误地处理 NaN。 NaN1 <= NaN2 和 NaN1 > NaN2 都需要评估为 false。

也许那本无名书的作者读到 a > 0 的运行速度比 a >= 1 快，并认为这是普遍适用的。

但这是因为涉及 0（因为 CMP 可以根据架构替换为例如 OR）而不是因为 <。

至少，如果这是真的，编译器可以简单地将 a <= b 优化为 !(a > b)，因此即使比较本身实际上更慢，除了最天真的编译器之外，您不会注意到任何差异.

TL;DR 答案

对于体系结构、编译器和语言的大多数组合，< 不会比 <= 快。

完整答案

其他答案集中在 x86 架构上，我不知道 ARM 架构（您的示例汇编器似乎是）足以专门评论生成的代码，但这是 micro-optimisation 的示例 非常特定于架构，并且既可能是反优化，也可能是优化。

因此，我建议这种 micro-optimisation 是 cargo cult 编程的一个示例，而不是最佳软件工程实践。

反例

可能有一些架构可以优化，但我知道至少有一种架构可能相反。古老的 Transputer 架构只有 等于 和 大于或等于 的机器代码指令，因此所有比较都必须从这些原语构建。

即便如此，在几乎所有情况下，编译器都可以以这样一种方式对评估指令进行排序，即在实践中，没有任何比较比其他任何比较有任何优势。但最坏的情况是，它可能需要添加反向指令 (REV) 来交换 operand stack 上的前两项。这是一个单字节指令，需要一个周期才能运行，因此开销可能最小。

概括

像这样的微优化是优化还是反优化取决于您使用的特定架构，因此养成使用特定架构微优化的习惯通常是个坏主意，否则您可能会本能地在不合适的时候使用一个，看起来这正是你正在阅读的书所提倡的。

它们具有相同的速度。也许在某些特殊的架构中，他/她说的是对的，但在 x86 家族中，至少我知道它们是相同的。因为为此，CPU 将执行减法 (a - b)，然后检查标志寄存器的标志。该寄存器的两位称为 ZF（零标志）和 SF（符号标志），它在一个周期内完成，因为它将通过一次掩码操作完成。

这将高度依赖于 C 编译到的底层架构。一些处理器和体系结构可能具有明确的等于、小于和等于指令，它们以不同的周期数执行。

不过，这将是非常不寻常的，因为编译器可以解决它，使其无关紧要。

即使有任何差异，您也不应该注意到差异。此外，在实践中，您必须额外执行 a + 1 或 a - 1 才能使条件成立，除非您要使用一些魔术常数，这无论如何都是一个非常糟糕的做法。

当我写这个答案的第一个版本时，我只是在看关于 < 的标题问题。 vs. <= 一般而言，不是常量 a < 901 与 a <= 900 的具体示例。许多编译器总是通过在 < 和 <= 之间进行转换来缩小常量的大小，例如，因为 x86 立即操作数对 -128..127 有更短的 1 字节编码。

对于 ARM，能够编码为立即数取决于能够将窄域旋转到单词中的任何位置。所以 cmp r0, #0x00f000 是可编码的，而 cmp r0, #0x00efff 则不是。因此，用于比较与编译时常量的缩小规则并不总是适用于 ARM。与 32 位 ARM 和 Thumb 模式不同，对于 cmp 和 cmn 等指令，AArch64 要么移位 12 位，要么不移位，而不是任意旋转。

< 与 <= 通常，包括运行时变量条件

在大多数机器上的汇编语言中，比较 <= 的成本与比较 < 的成本相同。无论您是在其上进行分支、对其进行布尔化以创建 0/1 整数，还是将其用作无分支选择操作的谓词（如 x86 CMOV），这都适用。其他答案只解决了这部分问题。

但这个问题是关于 C++ 运算符，即优化器的输入。 通常它们都同样有效；书中的建议听起来完全是假的，因为编译器总是可以转换他们在 asm 中实现的比较。但至少有一个例外，使用 <= 可能会意外创建编译器无法优化的内容。

作为一个循环条件，当 <= 阻止编译器证明循环不是无限的时，在某些情况下，<= 在质量上不同于 <。 这可以有很大的不同，禁用自动矢量化。

与有符号溢出 (UB) 不同，无符号溢出被明确定义为 base-2 环绕。有符号循环计数器通常不会出现这种情况，因为编译器不会基于有符号溢出 UB 进行优化：++i <= size 最终总是会变为假。 (What Every C Programmer Should Know About Undefined Behavior)

void foo(unsigned size) {
    unsigned upper_bound = size - 1;  // or any calculation that could produce UINT_MAX
    for(unsigned i=0 ; i <= upper_bound ; i++)
        ...

编译器只能以为所有可能的输入值保留 C++ 源代码的（已定义且可合法观察的）行为的方式进行优化，导致未定义行为的除外。

（一个简单的 i <= size 也会产生问题，但我认为计算上限是一个更现实的例子，它意外地为您不关心但编译器必须考虑的输入引入了无限循环的可能性。）

在这种情况下，size=0 导致 upper_bound=UINT_MAX，并且 i <= UINT_MAX 始终为真。因此，对于 size=0，这个循环是无限的，编译器必须尊重这一点，即使您作为程序员可能从不打算传递 size=0。如果编译器可以将此函数内联到一个调用者中，它可以证明 size=0 是不可能的，那么很好，它可以像对 i < size 一样进行优化。

如果循环 (Why are loops always compiled into "do...while" style (tail jump)?) 内不需要 i 的实际值，则像 if(!size) skip the loop; do{...}while(--size); 这样的 Asm 是优化 for( i<size ) 循环的一种通常有效的方法。

但这不会是无限的：如果使用 size==0 输入，我们将获得 2^n 次迭代。 （Iterating over all unsigned integers in a for loop C 可以在包括零在内的所有无符号整数上表示循环，但是没有进位标志就不容易，就像在 asm 中那样。）

由于循环计数器的环绕是可能的，现代编译器通常只是“放弃”，并且几乎没有积极地优化。

示例：从 1 到 n 的整数之和

使用无符号 i <= n 会破坏基于 Gauss 的 n * (n+1) / 2 公式优化具有封闭形式的 sum(1 .. n) 循环的 clang 习语识别。

unsigned sum_1_to_n_finite(unsigned n) {
    unsigned total = 0;
    for (unsigned i = 0 ; i < n+1 ; ++i)
        total += i;
    return total;
}

 # clang7.0 -O3 closed-form
    cmp     edi, -1       # n passed in EDI: x86-64 System V calling convention
    je      .LBB1_1       # if (n == UINT_MAX) return 0;  // C++ loop runs 0 times
          # else fall through into the closed-form calc
    mov     ecx, edi         # zero-extend n into RCX
    lea     eax, [rdi - 1]   # n-1
    imul    rax, rcx         # n * (n-1)             # 64-bit
    shr     rax              # n * (n-1) / 2
    add     eax, edi         # n + (stuff / 2) = n * (n+1) / 2   # truncated to 32-bit
    ret          # computed without possible overflow of the product before right shifting
.LBB1_1:
    xor     eax, eax
    ret

unsigned sum_1_to_n_naive(unsigned n) {
    unsigned total = 0;
    for (unsigned i = 0 ; i<=n ; ++i)
        total += i;
    return total;
}

# clang7.0 -O3
sum_1_to_n(unsigned int):
    xor     ecx, ecx           # i = 0
    xor     eax, eax           # retval = 0
.LBB0_1:                       # do {
    add     eax, ecx             # retval += i
    add     ecx, 1               # ++1
    cmp     ecx, edi
    jbe     .LBB0_1            # } while( i<n );
    ret

# "naive" inner loop
.L3:
    add     eax, 1       # do {
    paddd   xmm0, xmm1    # vect_total_4.6, vect_vec_iv_.5
    paddd   xmm1, xmm2    # vect_vec_iv_.5, tmp114
    cmp     edx, eax      # bnd.1, ivtmp.14     # bound and induction-variable tmp, I think.
    ja      .L3 #,       # }while( n > i )

 "finite" inner loop
  # before the loop:
  # xmm0 = 0 = totals
  # xmm1 = {0,1,2,3} = i
  # xmm2 = set1_epi32(4)
 .L13:                # do {
    add     eax, 1       # i++
    paddd   xmm0, xmm1    # total[0..3] += i[0..3]
    paddd   xmm1, xmm2    # i[0..3] += 4
    cmp     eax, edx
    jne     .L13      # }while( i != upper_limit );

     then horizontal sum xmm0
     and peeled cleanup for the last n%3 iterations, or something.