Python多处理:了解“块大小”背后的逻辑
哪些因素决定了此类chunksize方法的最佳论点multiprocessing.Pool.map()?该.map()方法似乎对其默认的块大小使用了任意启发式(如下所述);是什么激发了这种选择,并且基于某些特定的情况/设置,是否有一种更周到的方法? 示例-说我是: 传递iterable给的.map()元素大约有1500万; 24个核的机器上工作,使用默认processes = os.cpu_count()内multiprocessing.Pool()。 我天真的想法是给24名工人中的每人一个相等大小的块,即15_000_000 / 24625,000。大块应该在充分利用所有工人的同时减少营业额/间接费用。但这似乎没有为每个工人提供大批量生产的潜在弊端。这是一张不完整的图片,我想念什么? 我的问题的一部分源于if的默认逻辑chunksize=None:both.map()和.starmap()call .map_async(),看起来像这样: 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) == …