为何多进程场景下逐进程开销持续上升？6核12逻辑CPU测试遇耗时递增问题

核心认知偏差来源 #

• 对超线程CPU的并行能力预估错误：你用的6核12逻辑CPU，本质是6个独立的物理计算核心，每个物理核心通过超线程技术模拟2个逻辑线程。针对纯计算密集、无IO等待的任务，超线程几乎不会带来额外并行收益——两个逻辑线程需要共享同一个物理核心的计算单元，根本无法实现真正的同时计算，这台设备的无冲突并行上限是6个进程，而非12个。
• 对并行任务的开销预估不足：你预设的“进程数不超过CPU数量时整体耗时基本一致”，建立在任务无额外系统开销、无资源争抢的理想场景下，你的测试代码根本达不到这个前提。

实测耗时曲线的对应解释 #

你的测试数据刚好对应了并行计算时的典型资源争抢过程：

• 1-2进程阶段：两个进程只占用2个物理核心，几乎没有资源抢占，仅存在微小的进程启动、调度开销，因此耗时仅从14.9s微涨到15.5s，和理想状态偏差很小。
• 3-6进程阶段：进程数逐步占满全部6个物理核心，耗时从16.9s持续涨到24.1s。本来理想状态下6个进程各自占满一个物理核，整体耗时应该和单进程跑2亿次循环的14.9s差不多，这部分额外上涨的耗时来自两个方面：
  • 测试用到的random.random()调用需要频繁读写进程内的随机数生成器状态，随着进程数增加，内存带宽、CPU缓存的争抢逐步加剧，缓存失效率快速升高，CPU需要等待内存提供数据的时间占比越来越高。
  • 操作系统对多进程的轮询调度本身存在固定开销，哪怕进程数没超过物理核，调度上下文切换的成本也会随着进程数增加逐步累积。
• 7进程及以上阶段：进程数已经超过物理核总数，操作系统必须把每个物理核心的计算时间切分给多个进程轮询使用，每多一个进程，每个任务能分到的有效计算时间就被切薄一块，因此整体耗时会随着进程数增加近似线性上涨，和你实测的从29.1s涨到14进程的54.6s的曲线完全吻合。

代码本身的冗余问题 #

• 导入的Queue模块全程没有使用，属于冗余导入。
• 函数内一开始定义的num = []列表，在循环中被直接覆盖为随机数返回值，这行初始化没有任何实际作用。

效果验证参考 #

如果把测试逻辑替换成无额外内存读写的纯整数加法循环，比如循环内只做_ = i + 1的简单运算，就能观察到更接近理想状态的曲线：1-6个进程的耗时会和单进程基本持平，从第7个进程开始耗时才会明显线性上升。 #

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