安装MKL、OPENBLAS后哪类Numpy负载提速最高？MMM/QR/SVD性能对比

1. 三类Numpy计算负载的加速潜力排序 #

理论加速比从高到低依次是：

• 稠密矩阵乘法（MMM）：计算复杂度为O(n³)，访存开销占比极低，是最容易从优化BLAS库的多线程、SIMD指令优化中获得收益的负载，理想场景下8核可以拿到接近7x的加速。
• QR分解：计算复杂度同样为O(n³)，但存在更多访存密集和串行逻辑的步骤，加速比通常略低于MMM。
• SVD分解：存在大量不可并行的串行计算环节，且访存开销占比更高，三类负载中加速潜力最低。

2. 测试中性能随线程数上升反而下降的核心原因 #

2.1 计时函数选择错误 #

你使用的time.process_time()统计的是进程占用的所有CPU核心的时间总和，而非实际的墙上耗时。比如8线程跑满8核用了1秒，time.process_time()会返回接近8的数值，远高于单线程跑5秒返回的5，完全不能反映真实的运行耗时，替换为time.perf_counter()统计实际等待的时间即可得到符合预期的结果。

2.2 其他可能的影响因素 #

• 大矩阵内存瓶颈：20000x20000的float64矩阵单张就占3.2GB，乘法过程中还会生成临时矩阵，如果设备内存容量不足触发swap，或者内存带宽不足以支撑多线程并行的访存需求，就会出现多线程性能倒退的问题，可以先测试5000、10000阶的中等规模矩阵验证。
• 未开启线程绑定：MKL/OpenBLAS默认未开启核心绑定的话，线程会在不同核心间频繁调度，上下文切换开销会抵消并行收益，可以在环境变量中添加export MKL_DYNAMIC=FALSE（MKL场景）或者对应OpenBLAS的绑核参数降低调度开销。
• 小规模矩阵并行开销大于收益：2000阶的矩阵乘法计算量不大，多线程启动、同步的开销可能会盖过并行带来的收益，建议测试中等规模矩阵观察效果。

测试代码修改建议 #

将计时逻辑替换为以下内容即可：

import numpy as np
import time
import gc

sizes = [2000, 20000]
samples = np.zeros(5)
for n in sizes:
   # allocate outside the benchmark
   X = np.random.normal(size=(n, n))
   Y = X
   
   for i in range(2):
       Z = X @ Y

   # run 5 times
   for r in range(5):
      # 替换为perf_counter统计实际耗时
      start_time = time.perf_counter()
      Z = X @ Y
      samples[r] = time.perf_counter() - start_time

   X = Y = Z = None
   # remove unnecessary memory consumption 
   gc.collect()

   print(np.mean(samples))
   print(np.std(samples))

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