hen*_*dra 18 python iteration multiprocessing gdal
我编写了一种算法,它可以获取地理空间数据并执行许多步骤.输入数据是用于大光栅研究区域(约1.5亿像素)的多边形和协变量光栅的形状文件.步骤如下:
整个过程需要多次迭代(比如说100),但是当按顺序处理时,每次迭代当前需要花费一个多小时.对于每次迭代,最耗时的部分是步骤4和5.因为目标网格太大,我一直在处理它一个块(比如说1000行).
我有一个带有32 Gb RAM的6核CPU,所以在每次迭代中,我都使用Python的multiprocessing模块和一个Pool对象来同时处理多个块(步骤4和5),然后写出输出(预测)使用调用全局输出写入函数的回调函数到公共输出网格集.这似乎有效,但并不比处理串行中的每个块更快(实际上,它可能更慢).
所以我的问题是,有更有效的方法吗?我对多处理模块的Queue类感兴趣,但我不确定它是如何工作的.例如,我想知道如果有一个执行步骤4和5的队列然后将结果传递给执行步骤6的另一个队列是否更有效.或者这甚至是Queue的用途?
任何指针将不胜感激.
Python 的多处理能力的当前状态对于 CPU 密集型处理来说并不是很好。我不敢告诉您,使用该模块没有办法让它运行得更快multiprocessing,也不是您的使用multiprocessing有问题。
真正的问题是 Python 仍然受到GlobalInterpreterLock(GIL)规则的约束(我强烈建议幻灯片)。在 GIL 周围的工作中已经取得了一些令人兴奋的理论和实验进展。Python 3.2 事件包含一个新的 GIL,它解决了一些问题,但引入了其他问题。
目前,使用单个串行线程执行多个 Python 进程比尝试在一个进程内运行多个线程要快。这将允许您避免在线程之间获取 GIL 的问题(通过有效地拥有更多 GIL)。然而,只有当 Python 进程之间的 IPC 开销不会掩盖处理的好处时,这才有用。
Eli Bendersky 写了一篇不错的概述文章,介绍了他尝试通过多处理使 CPU 密集型进程运行得更快的经验。
值得注意的是,PEP 371希望通过引入该multiprocessing模块(以前是名为 的非标准包pyProcessing)来“回避”GIL。然而,GIL 似乎在 Python 解释器中仍然扮演着太大的角色,无法使其与 CPU 密集型算法很好地配合。许多不同的人都致力于删除/重写 GIL,但没有任何东西能够产生足够的吸引力使其成为 Python 版本。
| 归档时间: |
|
| 查看次数: |
1579 次 |
| 最近记录: |