Python多处理：理解chunksize背后的逻辑`

Question

什么因素决定了像multiprocessing.Pool.map()这样的方法的最佳chunksize参数？.map()方法似乎对其默认块大小使用了一种任意的启发式方法（如下所述）；是什么促使了这种选择，是否有基于某些特定情况/设置的更周到的方法？

比如说我是：

• 把一个iterable传递给.map()，这个iterable有大约1500万个元素
• 在24核的机器上工作，并在multiprocessing.Pool()内使用默认的^{}。

我天真的想法是给24个工人每人一个同样大小的块，即15_000_000 / 24或625000块。大块应减少周转/管理费用，同时充分利用所有工人。但这似乎忽略了给每个工人大量生产的一些潜在不利因素。这是一张不完整的照片吗？我遗漏了什么？

---

我的部分问题源于ifchunksize=None的默认逻辑：同时.map()和.starmap()调用^{}，如下所示：

def _map_async(self, func, iterable, mapper, chunksize=None, callback=None,
               error_callback=None):
    # ... (materialize `iterable` to list if it's an iterator)
    if chunksize is None:
        chunksize, extra = divmod(len(iterable), len(self._pool) * 4)  # ????
        if extra:
            chunksize += 1
    if len(iterable) == 0:
        chunksize = 0

背后的逻辑是什么？这意味着块大小将更接近15_000_000 / (24 * 4) == 156_250。把len(self._pool)乘以4的目的是什么？

这使得生成的块大小比我上面的“原始逻辑”小4个因子，这包括将iterable的长度除以pool._pool中的工作者数量。

最后，还有一个来自Python文档的snippet进一步激发了我的好奇心：

The chunksize argument is the same as the one used by the map() method. For very long iterables using a large value for chunksize can make the job complete much faster than using the default value of 1.

---

_{有帮助但有点太高的相关答案：Python multiprocessing: why are large chunksizes slower?。}

Answer 1

我认为你缺少的部分原因是你天真的估计假设每个工作单元花费的时间相同，在这种情况下，你的策略是最好的。但是，如果某些作业比其他作业完成得更快，则某些核心可能会变得空闲，等待缓慢的作业完成。

因此，通过将块分解成4倍多的块，如果一个块提前完成，那么核心可以开始下一个块（而其他核心继续处理速度较慢的块）。

我不知道他们为什么选择因子4，但这将是在最小化映射代码的开销（这需要尽可能大的块）和平衡块占用不同时间（这需要尽可能小的块）之间的权衡。