为何多进程实现CMA-ES时迭代速度反而变慢？
进程调度与资源竞争：虽然总进程数是8（2实例×4进程），但Python
multiprocessing默认的spawn启动方式会带来额外开销；若适应度函数存在IO操作、内存共享或隐性全局锁依赖，会加剧进程间竞争。另外，CMA-ES实例主进程本身也要执行协方差矩阵更新等计算，加上8个评估进程，总CPU负载可能超出8核处理能力，导致上下文切换开销飙升。内存带宽瓶颈：CMA-ES迭代涉及大量矩阵运算，多实例并行时内存读写并发需求剧增。如果适应度函数还需加载大量数据，多进程同时访问内存会导致带宽饱和，CPU陷入等待内存数据的状态，利用率上不去，耗时自然翻倍。
进程池配置不合理：每个CMA实例单独创建
Pool(4)会导致进程池间资源抢占。建议改为全局共享一个Pool(8)，让所有实例的适应度评估任务统一提交到全局池，避免重复创建销毁进程，提升资源调度合理性。忽略CMA实例主进程开销：不要只计算适应度评估的进程，每个CMA实例的主进程也要执行种群生成、参数更新等逻辑。2个主进程+8个评估进程共10个进程在8核机器上运行，必然引发频繁调度，增加额外开销。可尝试减少每个实例的评估进程数，比如每个实例用3个进程，总进程数2+6=8，刚好匹配核心数，观察性能变化。
适应度函数并行效率上限：如果单个适应度函数计算量极小（比如耗时小于100ms），多进程的启动、通信开销会抵消并行收益。这种情况下建议批量评估个体，减少进程通信次数；若计算密集型任务仍无改善，可检查是否存在GIL影响（不过计算密集型场景多进程本身是合理选择）。
CPU亲和性优化：默认操作系统会随机调度进程到不同核心，可能导致同一CMA实例的进程分散到多个核心，增加缓存失效概率。可通过
psutil库给进程绑定固定核心，比如将第一个实例的主进程+4个评估进程绑定到核心0-3，第二个实例绑定到核心4-7，减少跨核心调度的缓存开销。示例代码：
import psutil import os def set_core_affinity(core_ids): p = psutil.Process(os.getpid()) p.cpu_affinity(core_ids) # 在每个评估进程启动时调用对应核心列表
- 禁用CMA内部多线程：检查
cma包依赖的线性代数库（如OpenBLAS、MKL）是否启用了内部多线程，若外部多进程与内部多线程竞争，会导致CPU过载。可通过环境变量禁用内部多线程：
import os os.environ["OMP_NUM_THREADS"] = "1" os.environ["MKL_NUM_THREADS"] = "1"
验证步骤
先单独运行1个CMA实例，记录单迭代时间；再运行2个实例，同时用htop、vmstat监控CPU利用率、内存带宽：
- 若CPU利用率未达100%但耗时翻倍，大概率是内存带宽或进程调度问题；
- 若CPU利用率超100%（超线程开启时），说明进程数过多导致上下文切换开销剧增。
内容的提问来源于stack exchange，提问作者Valle Hane
