为何在Apple M1 Pro上int相加返回long的性能远超其他方式？

结合你的基准测试结果和ARM64架构（M1 Pro）的特性，核心原因可以从以下几个方面分析：

1. int运算的溢出检查开销 #

.NET的RyuJIT编译器在默认场景下，会为int类型的算术运算保留溢出检查逻辑。在AddIntReturnInt方法中，每次循环的result += a + b + c都是int类型累加，JIT需要额外生成指令检测累加是否超出int范围，这会增加每次迭代的指令开销。

而在AddIntReturnLong方法中，虽然a + b + c是int运算，但结果会赋值给long类型的result。此时JIT可以判断：即使int相加溢出，转换为long仅做符号位扩展，不会触发运行时异常，因此可以完全优化掉溢出检查指令，减少了每次迭代的指令数。

2. ARM64架构的寄存器与指令特性 #

ARM64的通用寄存器均为64位宽度，处理32位和64位基础运算的指令周期几乎一致，但存在关键差异：

• AddIntReturnInt中，每次累加后需要将结果截断为32位（因result是int），会额外生成截断指令；
• AddIntReturnLong中，所有运算直接在64位寄存器中完成，无需截断操作，指令更精简。

3. AdvSIMD向量化优化 #

你的测试环境启用了Arm64 RyuJIT AdvSIMD（从BenchmarkDotNet输出可见）。AddIntReturnLong的代码结构更适合JIT做向量化优化：

• long类型累加可直接利用AdvSIMD的64位向量指令，一次迭代处理多个累加操作；
• AddIntReturnInt的int累加受限于32位宽度，向量化效率更低，甚至JIT无法对其做有效向量化。

这直接解释了AddIntReturnLong耗时仅为另外两种方法1/3的原因——向量化让单次循环处理了更多计算量。

4. 循环优化的差异 #

JIT对不同类型的循环会采取不同优化策略：

• AddIntReturnLong的循环变量和累加变量均为64位，JIT可高效进行循环展开、寄存器分配等优化，减少循环分支开销；
• AddIntReturnInt的32位累加变量可能导致寄存器分配冲突，或JIT无法进行深度循环展开优化。

验证思路 #

若要进一步验证，可尝试：

• 在AddIntReturnInt方法中用unchecked块包裹循环，观察性能是否接近AddIntReturnLong；
• 通过BenchmarkDotNet的--disasm参数输出JIT生成的汇编代码，对比三种方法的指令差异，重点查看溢出检查、截断指令和向量化指令的有无。

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