并行处理RGB图像未提升运行时间的原因排查求助

你的并行处理未达到预期提速效果，反而单通道耗时增加，核心原因是numpy底层BLAS库的多线程与Python多进程的资源竞争，结合进程调度开销共同导致，具体拆解及解决办法如下：

核心原因 #

1. BLAS多线程与多进程冲突
   numpy的np.linalg.svd依赖OpenBLAS/MKL等线性代数库，这些库默认会启用多线程并行计算。串行处理时，单个SVD任务会占用多个CPU核心，因此单通道耗时仅20秒；当你用Pool(3)启动3个进程同时执行SVD时，每个进程的BLAS又会启动多线程，导致所有任务争抢CPU核心，大量上下文切换直接拉长了单个任务的执行时间（到70秒），而CPU资源饱和后，总耗时自然和串行处理基本持平。

2. 多进程的额外开销
   进程创建、进程间numpy数组的序列化/反序列化也会产生少量额外耗时，但这不是总时间未下降的主要原因。

解决方案 #

1. 限制BLAS线程数，避免资源竞争 #

在代码开头添加环境变量设置，强制每个进程的BLAS仅使用1个线程，让多进程真正利用独立CPU核心：

import os
# 针对OpenBLAS/OpenMP后端设置
os.environ["OMP_NUM_THREADS"] = "1"
# 针对MKL后端设置（若你的numpy使用MKL）
os.environ["MKL_NUM_THREADS"] = "1"

设置后，每个SVD任务仅占用1个核心，3个进程并行时刚好填满3个核心，单通道耗时会接近串行时的单线程耗时（略高于20秒，存在少量进程调度开销），总耗时会降至接近20秒。

2. 优化矩阵乘法步骤 #

代码中np.diag(s[0:k_rank])会创建完整对角矩阵，对大k值会浪费内存和计算时间，可改用广播乘法优化：

# 替换原k_rank_approx计算逻辑
k_rank_approx = u[:, :k_rank] @ (s[:k_rank, None] * v[:k_rank, :])

这种方式无需创建对角矩阵，直接通过广播完成计算，能减少内存占用和计算耗时，串行、并行场景均适用。

3. 匹配进程池大小与CPU核心数 #

若你的CPU核心数多于3，保持Pool(3)即可（对应RGB三通道）；若核心数少于3，建议将进程池大小设为核心数，避免过度竞争。

验证建议 #

先单独测试限制BLAS线程后的串行耗时：设置OMP_NUM_THREADS=1后，单通道SVD耗时会从20秒涨到接近70秒（从多线程变为单线程），这能验证BLAS多线程是原串行提速的核心原因。之后再运行并行代码，总耗时应会降至接近单线程单通道的耗时。

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