为何开启numba fastmath=True后性能反而下降？

出现这种和教程相反的测试结果，主要是以下几方面因素导致：

• 硬件架构差异
  不同CPU对fastmath涉及的浮点优化指令支持程度不同。教程的测试环境可能是对快速浮点运算（如FMA、近似平方根指令）优化友好的高端CPU，而你的CPU可能不支持相关高级指令集，或者对这类指令的执行效率更低，fastmath带来的优化收益抵不上额外的指令转换开销，最终导致性能下降。

• 并行与fastmath的优化冲突
  当开启parallel=True时，Numba会针对并行归约（比如示例中的累加操作）做特定优化，比如线程局部累加再合并，减少线程同步开销。而fastmath=True会改变编译器对浮点运算的调度策略（比如调整指令顺序、放宽浮点运算精度约束），可能破坏了原本并行归约的高效逻辑，反而增加了计算或同步的额外开销。

• 测试场景细节差异

  • 数据规模：如果你的测试数组远小于教程使用的量级，fastmath的优化收益不足以抵消它带来的编译、指令调度开销；
  • 数据特征：若测试数组中的数值不需要fastmath的近似优化（比如无NaN/Inf、数值分布均匀），fastmath改变运算流程的代价会超过收益；
  • 版本差异：不同版本的Numba对parallel和fastmath的组合优化策略不同，你使用的版本可能存在两者兼容性问题，导致负优化。

验证建议 #

• 测试更大规模的数组（比如长度提升至1e7级别），观察fastmath是否能体现性能优势；
• 关闭parallel=True，单独测试单线程下fastmath=True/False的性能，排查是否是并行组合导致的问题；
• 检查你的CPU是否支持AVX512、FMA等高级浮点指令集，若不支持，fastmath的优化效果会大打折扣；
• 升级Numba到最新稳定版本，看是否修复了相关优化逻辑的问题。

测试代码 #

from numba import njit, prange
import numpy as np

@njit(parallel=True)
def do_sum_parallel(A):
    # each thread can accumulate its own partial sum, and then a cross
    # thread reduction is performed to obtain the result to return
    n = len(A)
    acc = 0.
    for i in prange(n):
        acc += np.sqrt(A[i])
    return acc

@njit(parallel=True, fastmath=True)
def do_sum_parallel_fast(A):
    n = len(A)
    acc = 0.
    for i in prange(n):
        acc += np.sqrt(A[i])
    return acc

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