因为NumPy底层已通过OpenBLAS/MKL等多线程BLAS库自动并行化矩阵运算，再套用concurrent.futures会引入调度开销、内存拷贝和GIL争抢，反而降低性能；正确做法是直接控制BLAS线程数（如OPENBLAS_NUM_THREADS=4）。
为什么 concurrent.futures 对矩阵运算几乎没用
直接套用 ThreadPoolExecutor 或 ProcessPoolExecutor 去并行 numpy.dot、np.linalg.solve 这类操作，通常不会提速，反而更慢。根本原因是：NumPy 默认已启用多线程 BLAS（如 OpenBLAS、Intel MKL），底层矩阵乘法本身就在用满 CPU 核心；再套一层 Python 进程/线程调度，只会引入额外开销和内存拷贝。
- 验证方法：运行
numpy.show_config()，确认blas_opt_info中有libraries = ['openblas']或mkl_rt - 典型误用：把一个大矩阵切块后丢给
ProcessPoolExecutor.submit()，结果每个子进程都重新加载 NumPy + BLAS，还触发 GIL 争抢或序列化瓶颈 - 真正适合
concurrent.futures的场景是“多个独立的大矩阵运算任务”，比如批量处理 1000 个不同A_i @ b_i，且A_i之间无依赖
如何让 numpy 真正跑满多核（不写 C）
关键不是换库，而是控制 BLAS 线程数 —— 默认常设为 1 或系统逻辑核数，但实际负载下未必最优。尤其在容器、云实例或混部环境中，盲目开满可能引发 NUMA 争抢或缓存抖动。
- 设置环境变量最可靠：
OMP_NUM_THREADS=4、OPENBLAS_NUM_THREADS=4、MKL_NUM_THREADS=4（三者选一，取决于你用的 BLAS 后端） - 运行时动态控制（仅限部分后端）：
import mkl; mkl.set_num_threads(4)，但需提前 import，且对 OpenBLAS 无效 - 验证是否生效：用
htop观察 CPU 使用率，或运行np.random.random((2000,2000)) @ np.random.random((2000,2000))时看 top 输出的线程数 - 注意：线程数 ≠ 物理核心数；实测中，设为物理核数的 75%（如 8 核设 6 线程）常比设满更稳
numba 并行化自定义矩阵循环时的坑
如果你写的是非标准矩阵操作（比如逐元素条件更新、稀疏索引累加），@njit(parallel=True) 能显著加速，但极易出错。
- 必须显式指定
prange()替代range()，否则parallel=True不生效 - 禁止在并行区修改全局数组 shape 或 dtype；所有写入必须是预分配好、索引明确的数组切片
- 常见崩溃错误：
TypingError: Failed in nopython mode pipeline... parallel for loop cannot be scheduled，往往因循环变量被间接引用（如用for i in indices:而indices是 list） - 简单示例有效写法：
@njit(parallel=True) def mat_update(A, B): for i in prange(A.shape[0]): for j in prange(A.shape[1]): if A[i, j] > 0.5: B[i, j] = A[i, j] * 2
何时该换 cupy 或 torch？
当单机 CPU 已到吞吐瓶颈（比如 10k×10k 矩阵乘法持续 2s+），且你有 NVIDIA GPU，切换成本其实很低 —— 但别只图快，得看数据生命周期。
立即学习“Python免费学习笔记（深入）”；
-
cupy接口几乎 1:1 兼容 NumPy，但所有数组必须显式创建在 GPU 上：x = cp.array(np_array)；CPU↔GPU 拷贝开销极大，务必避免频繁往返 -
torch更适合带自动微分或后续要进训练流程的场景；torch.mm()在 GPU 上默认启用 cuBLAS，但torch.compile()（PyTorch 2.0+）对静态矩阵运算收益有限 - 真实瓶颈判断：用
nvtop看 GPU 利用率是否长期 - 混合策略更实用：CPU 预处理 → GPU 批量计算 → CPU 后处理，中间尽量用 pinned memory 减少拷贝延迟
实际加速效果高度依赖矩阵规模、稀疏性、内存带宽和 BLAS 实现版本。别迷信“并行库”三个字，先用 numpy.show_config() 和 timeit 定位真瓶颈在哪一层。
