python - 如何找到理想的并行进程数以使用 python 多处理运行？

Question

试图找出正确的并行进程数以运行 python multiprocessing .

以下脚本在 8 核、32 GB (Ubuntu 18.04) 机器上运行。 (下面测试时只有系统进程和基本用户进程在运行。)

使用以下内容测试了 multiprocessing.Pool 和 apply_async:

from multiprocessing import current_process, Pool, cpu_count
from datetime import datetime
import time

num_processes = 1 # vary this

print(f"Starting at {datetime.now()}")
start = time.perf_counter()

print(f"# CPUs = {cpu_count()}") # 8
num_procs = 5 * cpu_count() # 40


def cpu_heavy_fn():
    s = time.perf_counter()
    print(f"{datetime.now()}: {current_process().name}")
    x = 1
    for i in range(1, int(1e7)):
        x = x * i
        x = x / i
    t_taken = round(time.perf_counter() - s, 2)
    return t_taken, current_process().name


pool = Pool(processes=num_processes)

multiple_results = [pool.apply_async(cpu_heavy_fn, ()) for i in range(num_procs)]
results = [res.get() for res in multiple_results]
for r in results:
    print(r[0], r[1])

print(f"Done at {datetime.now()}")
print(f"Time taken = {time.perf_counter() - start}s")

结果如下:

num_processes total_time_taken
1 28.25
2 14.28
3 10.2
4 7.35
5 7.89
6 8.03
7 8.41
8 8.72
9 8.75
16 8.7
40 9.53

以下内容对我来说很有意义:

• 一次运行一个进程每个进程大约需要 0.7 秒，因此运行 40 次大约需要 28 秒，这与我们上面观察到的一致。
• 一次运行 2 个进程应该将时间减半，这是在上面观察到的(~14 秒)。
• 一次运行 4 个进程应该进一步将时间减半，这是在上面观察到的(~7 秒)。
• 将并行度增加到超过内核数 (8) 应该会降低性能(由于 CPU 争用)，并且观察到(某种程度上)。

没有意义的是:

• 为什么并行运行 8 的速度不是并行运行 4 的两倍，即为什么不是 ~3.5 秒？
• 为什么一次同时运行 5 到 8 个比同时运行 4 个更糟糕？有 8 个核心，但为什么整体运行时间更差？ (当并行运行 8 个时，htop 显示所有 CPU 的利用率接近 100%。当并行运行 4 个时，只有 4 个达到 100%，这是有道理的。)

Answer 1

Q : "Why is running 5 to 8 in parallel at a time worse than running 4 at a time?"

好吧，有几个原因，我们将从一个静态的、最容易观察到的原因开始:

由于硅设计(他们为此使用了一些硬件技巧)无法扩展超过 4。

所以最后 Amdahl's Law解释并提升了 +1 的 processors 升级数量的加速是 4，任何下一个 +1 都不会像在 { 2, 3, 4 }-案例:

此 lstopo CPU 拓扑图有助于开始解码为什么(此处针对 4 核，但逻辑与 8 核芯片相同 -在您的设备上运行 lstopo 以在体内查看更多详细信息):

┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Machine (31876MB)                                                                                                 │
│                                                                                                                   │
│ ┌────────────────────────────────────────────────────────────┐                      ┌───────────────────────────┐ │
│ │ Package P#0                                                │  ├┤╶─┬─────┼┤╶───────┤ PCI 10ae:1F44             │ │
│ │                                                            │      │               │                           │ │
│ │ ┌────────────────────────────────────────────────────────┐ │      │               │ ┌────────────┐  ┌───────┐ │ │
│ │ │ L3 (8192KB)                                            │ │      │               │ │ renderD128 │  │ card0 │ │ │
│ │ └────────────────────────────────────────────────────────┘ │      │               │ └────────────┘  └───────┘ │ │
│ │                                                            │      │               │                           │ │
│ │ ┌──────────────────────────┐  ┌──────────────────────────┐ │      │               │ ┌────────────┐            │ │
│ │ │ L2 (2048KB)              │  │ L2 (2048KB)              │ │      │               │ │ controlD64 │            │ │
│ │ └──────────────────────────┘  └──────────────────────────┘ │      │               │ └────────────┘            │ │
│ │                                                            │      │               └───────────────────────────┘ │
│ │ ┌──────────────────────────┐  ┌──────────────────────────┐ │      │                                             │
│ │ │ L1i (64KB)               │  │ L1i (64KB)               │ │      │               ┌───────────────┐             │
│ │ └──────────────────────────┘  └──────────────────────────┘ │      ├─────┼┤╶───────┤ PCI 10bc:8268 │             │
│ │                                                            │      │               │               │             │
│ │ ┌────────────┐┌────────────┐  ┌────────────┐┌────────────┐ │      │               │ ┌────────┐    │             │
│ │ │ L1d (16KB) ││ L1d (16KB) │  │ L1d (16KB) ││ L1d (16KB) │ │      │               │ │ enp2s0 │    │             │
│ │ └────────────┘└────────────┘  └────────────┘└────────────┘ │      │               │ └────────┘    │             │
│ │                                                            │      │               └───────────────┘             │
│ │ ┌────────────┐┌────────────┐  ┌────────────┐┌────────────┐ │      │                                             │
│ │ │ Core P#0   ││ Core P#1   │  │ Core P#2   ││ Core P#3   │ │      │     ┌──────────────────┐                    │
│ │ │            ││            │  │            ││            │ │      ├─────┤ PCI 1002:4790    │                    │
│ │ │ ┌────────┐ ││ ┌────────┐ │  │ ┌────────┐ ││ ┌────────┐ │ │      │     │                  │                    │
│ │ │ │ PU P#0 │ ││ │ PU P#1 │ │  │ │ PU P#2 │ ││ │ PU P#3 │ │ │      │     │ ┌─────┐  ┌─────┐ │                    │
│ │ │ └────────┘ ││ └────────┘ │  │ └────────┘ ││ └────────┘ │ │      │     │ │ sr0 │  │ sda │ │                    │
│ │ └────────────┘└────────────┘  └────────────┘└────────────┘ │      │     │ └─────┘  └─────┘ │                    │
│ └────────────────────────────────────────────────────────────┘      │     └──────────────────┘                    │
│                                                                     │                                             │
│                                                                     │     ┌───────────────┐                       │
│                                                                     └─────┤ PCI 1002:479c │                       │
│                                                                           └───────────────┘                       │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

仔细观察，就像调用 hwloc-tool: lstopo-no-graphics -.ascii 一样，显示 < strong>相互处理独立性结束的地方 - 这里是共享 L1-instruction-cache(L3一个是共享的，但位于层次结构的顶部，其大小仅对大型问题解决者造成困扰，而不是我们的情况)

---

接下来是一个更糟糕的可观察到的原因为什么在 8 进程上更糟:

Q : "Why does running 8 in parallel not twice as fast as running 4 in parallel i.e. why is it not ~3.5s?"

因为热管理。

加载到 CPU 内核上的工作越多，以 ~3.5+ GHz 驱动电子通过硅迷宫时产生的热量就越多。热限制是指那些阻止 CPU 计算能力进一步提高性能的限制，这仅仅是因为物理定律，正如我们所知，不允许超出某些 Material 定义的限制。

接下来会发生什么？
CPU 设计没有规避物理学(这是不可能的)，而是我们，用户 - 通过向我们 promise 具有 ~3.5+ GHz 的 CPU 芯片(但实际上, CPU 只能在很短的时间内使用这个时钟速率 - 直到散发的热量不会使硅接近热极限 - 然后，CPU 将决定降低自己的时钟速率 作为过热防御步骤(这会降低性能，不是吗？)或者一些 CPU 微架构可能会跳(移动处理流程)到另一个，免费的，因此更酷的 CPU 内核(这保证了更高的时钟速率那里(至少在一些小的时间内)但也降低了性能，就像跳跃一样不会在零时间发生，也不会以零成本发生(缓存丢失、重新获取等)

这张图片显示了内核跳跃情况的快照 - 内核 0-19 变得太热并且处于热节流上限之下，而内核 20-39 可以(至少现在)全速运行:

---

结果？

无论是热约束(将 CPU 浸入液氮池中都曾在“流行”杂志节目中进行过演示，但对于任何可持续计算来说都不是一个合理的选择，因为从深度冷冻状态到低温状态的机械应力6+ GHz 时钟速率 Steam 形成的过热器会使 CPU 主体破裂，并且会在少数工作负载事件中导致 CPU 因破裂和机械疲劳而报废- 由于任何严肃项目的负投资返回率，所以这是一个禁区。

基于体内预测试的良好冷却和适当规模的 worker 池是这里唯一确定的赌注。

其他架构: