为何Python原生环境下2×2循环展开更慢？JIT无Python模式却提速

已知以下两个函数的计算结果完全一致（假设输入数组长度为偶数）：

• 在原生Python环境中，输入1000万个浮点数时，2×2循环展开的函数运行速度反而慢30%；
• 启用@jit(nopython=True)的无Python模式后，该展开函数的运行速度提升约2.5倍。

核心疑问：
为何原生Python无法通过循环展开获得性能提升？两种代码在编译与运行机制上的底层差异是什么？

示例代码 #

# @jit(nopython=True)
def func1(array):
    numSum = 0

    for i in range(array.shape[0]):
        numSum += array[i]

    return numSum

# 2x2 循环展开版本
# @jit(nopython=True)
def unrolledFunc1(array):
    numSum0 = 0
    numSum1 = 0 

    for i in range(0, array.shape[0]-1, 2):
        numSum0 += array[i] 
        numSum1 += array[i+1] 

    numSum = numSum0 + numSum1 

    return numSum

问题解答 #

原生Python中循环展开失效的原因 #

Python是解释型语言，代码逐行解释执行，没有提前编译优化的过程，循环展开带来的额外开销远大于它能节省的循环控制成本：

• 单次循环内的操作从1次累加变成2次，而Python的+=、数组索引都是动态操作——每一次操作都要做类型检查、属性查找，额外的操作直接加重了解释器的执行负担；
• 原循环的range生成的是轻量级迭代器，展开后虽减少了循环次数，但每次循环里的两次数组访问、两次累加操作，会触发更多Python层面的动态操作，这些操作的开销远超过循环次数减少带来的收益；
• 单线程下全局解释器锁（GIL）的持有时间并未减少，反而因为更多操作延长了执行时间，进一步放大了性能差距。

Numba JIT与原生Python的底层机制差异 #

Numba的@jit(nopython=True)会将Python代码编译为机器码，完全绕过Python解释器的执行流程：

1. 静态类型推断：编译阶段会推断出数组、变量的类型，把动态的Python操作转换成静态的机器码指令，不需要在运行时重复做类型检查；
2. CPU指令级并行利用：循环展开后的两次累加操作可以被CPU并行执行，同时减少了循环分支判断的次数（比如原循环要做1000万次分支判断，展开后只需要500万次）；
3. 直接内存操作：编译后的代码直接访问数组的底层内存，省去了Python数组对象__getitem__方法的调用开销；
4. 消除Python层级开销：机器码不需要处理Python的对象引用、垃圾回收等机制，所有操作都是原生CPU指令，性能和C/C++代码接近。

简言之，原生Python的瓶颈在于解释器的动态执行开销，循环展开反而增加了动态操作的数量；而Numba把代码转换成静态编译的机器码，循环展开能真正发挥减少循环控制、利用CPU并行的优势。

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