Numba使用prange并行时线程数越多运行越慢的原因

这个现象和Numba的并行实现bug没关系，根因非常明确：测试任务的计算量太小，多线程的调度开销远大于并行带来的计算收益，具体拆解如下：

• 你的测试用例计算量极低：prange外层仅迭代10次，内层循环仅10次，总共只做100次整数加法+数组赋值，单线程跑完整个函数仅需897纳秒，连1微秒都不到。
• 多线程本身存在固定调度开销：Numba开启并行时，需要完成线程唤醒、任务拆分、线程间同步、缓存一致性维护、线程回收等一系列操作，这套流程的固有开销就在微秒级。你开的线程数越多，线程锁竞争、伪共享、空转等待的额外开销就越高，从测试结果就能看到，线程数从1涨到16的过程中，耗时基本线性上涨，完全是调度成本在拖慢速度，根本没轮到计算环节出力。
• 额外的性能损耗因素：你每次调用函数都新建大小仅10*10的小数组，整个数组完全能塞进CPU的L1缓存，多线程访问时很容易触发缓存行伪共享，进一步放大性能损失；另外你的外层循环只有10次迭代，开超过10个线程时，多出来的线程分不到任何计算任务，只会空耗调度资源。

并行加速只适用于计算量足够大的场景，只有当单线程计算耗时远大于线程调度开销（通常至少是毫秒级）时，多线程才能带来正收益。测试时还要注意提前预热编译、避免编译器直接把常量计算优化掉，参考代码如下：

import numpy as np
from numba import njit, prange, set_num_threads
import time

@njit(parallel=True, fastmath=True)
def test_large(arr_size):
    x = np.empty((arr_size, arr_size))
    # 外层prange迭代次数足够多，计算量足以摊薄调度开销
    for i in prange(arr_size):
        for j in range(arr_size):
            # 加入简单浮点计算，避免编译器直接折叠常量结果
            x[i, j] = i + j + np.sin(i) * np.cos(j)
    return x

# 预热编译，排除首次JIT编译的耗时干扰
test_large(10)

# 单线程基准测试
set_num_threads(1)
start = time.perf_counter()
test_large(2000)
print(f"1线程耗时: {time.perf_counter() - start:.3f}s")

# 多线程测试，2700X为8物理核，优先测试8线程性能
set_num_threads(8)
start = time.perf_counter()
test_large(2000)
print(f"8线程耗时: {time.perf_counter() - start:.3f}s")

额外提醒：Ryzen 7 2700X的SMT超线程对这种纯计算密集型负载提升非常有限，日常使用设置线程数等于物理核心数（8个）即可，开满16个逻辑线程很多时候反而会因为核心内部资源争抢出现性能下降。

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