Go标准库中IsSorted为何采用反向遍历切片的实现？

核心原因：CPU指令层面的效率差异 #

你观察到的反向遍历性能更优，本质上和缓存局部性关系不大（正反向都是连续访问数组，CPU预取器都能很好处理），核心差异来自循环条件的指令效率和寄存器利用：

1. 循环条件的判断成本
   反向遍历的循环条件是i > 0，在编译后的汇编中，只需要用test指令检查寄存器中的i是否为0（单周期指令，无需额外操作数）；而正向遍历的i < n，需要将i和n做比较，即使n被提前放到寄存器中，也需要多一步cmp指令，并且要维护n对应的寄存器，增加了寄存器压力。

   更关键的是，反向循环可以把变量递减和条件判断更紧凑地结合：比如dec %rax（i--）后直接用jnz（非零则继续），相当于把递减和判断合并成近乎原子的操作；而正向循环需要先inc %rax（i++），再cmp %rbx, %rax（比较i和n），最后jl（小于则继续），多了一次比较指令的开销。

2. 寄存器的紧凑复用
   反向遍历只需要维护一个循环变量寄存器（存储i），而正向遍历需要同时维护i和n两个寄存器。在泛型函数中，本来寄存器资源就相对紧张，更少的寄存器占用能减少寄存器溢出到内存的概率，进一步提升执行效率。

为什么优化后的正向版本仍稍逊一筹？ #

你把len(slice)-1移到循环外后，确实消除了每次循环计算长度的开销，但循环条件i < n的本质没有改变：仍然需要将i与n做比较，而反向的i > 0只是检查零值，指令更短、执行更快。这种单次循环的微小差异，在大量循环迭代后会累积成可观测的性能差距。

补充：Go的汇编特性 #

Go确实有自己的汇编语法（基于Plan 9汇编），和常见的x86/x86_64汇编在语法和伪指令上有区别，但底层映射的CPU指令逻辑是一致的——你提到的Compiler Explorer可以直观看到Go代码编译后的汇编输出，能更清晰地对比正反向遍历的指令差异。

内容的提问来源于stack exchange，提问作者scottwillmoore