map 上的 Python 多处理

Question

我刚刚研究了这个文档部分 enter link description here

据我了解这个功能

import multiprocessing
pool = multiprocessing.Pool()
print pool.map(f, range(10))

将创建一个任务 block ，其数量等于核心数量。结果将与从 sequnze 获得输入的顺序相同。

文档还说 --- 将阻塞直到完成:

假设上面的 f 是一个复杂的函数。我们有 4 个 CPU，因此 block 大小为 4，它会阻塞直到所有 4 个都完成，然后才获取下一个 block 吗？

所以在更坏的情况下，3 个空闲核心会闲置很长时间，直到最后一个核心完成？

Answer 1

您的印象似乎是 chunksize 将与核心数相匹配。这是不正确的。如果未指定，chunksize 有一个实现定义的值，它不等于核心数，至少在 CPython(引用解释器)上是这样。在撰写本文时，在 Python 2.7 和 3.7 上，使用的计算是:

    if chunksize is None:
        chunksize, extra = divmod(len(iterable), len(self._pool) * 4)
        if extra:
            chunksize += 1

len(self._pool)是worker进程数，len(iterable)是input iterable(也就是list 如果它没有定义的长度，则进行验证。

所以对于你的情况，计算是:

        chunksize, extra = divmod(10, numcores * 4)
        if extra:
            chunksize += 1

对于四核机器(例如)，将计算 chunksize, extra = 0, 10，然后 if 检查将更改 chunksize 到 1。所以每个 worker 都会接受一个输入值(0、1、2 和 3 几乎会立即被抓取)，然后当每个 worker 完成时，它会再抓取一个项目。假设所有项目花费的时间大致相同，您将在完全占用(使用 4/4 个核心)的情况下进行两轮，然后在半占用(使用 2/4 个核心)的情况下进行一轮.最坏的情况是最后一个开始的任务运行时间最长。如果这是提前知道的，您应该尝试组织您的输入以防止这种情况发生(首先放置最昂贵的元素，因此在未完全占用的情况下运行的最终任务很短并且完成速度很快，从而最大限度地提高并行性)；否则，这是不可避免的。

对于更多的任务，是的，默认的 chunksize 会增加，例如对于 4 个内核上的 100 个输入，您的 chunksize 为 7，产生 15 个 block ，最后一个 block 大小过小。所以是的，对于运行时间变化很大的任务，你会冒着低占用率的长尾风险。如果这有风险，请将您的 chunksize 显式设置为 1；它降低了整体性能(使其更接近 imap)，但它消除了一个工作人员在一个 block 中处理 7 项中的第 1 项而所有其他核心都处于空闲状态的可能性。