我不确定这是否更多地被视为操作系统问题,但我想我会在这里问一下,以防有人对 Python 的结局有所了解。
我一直在尝试使用 joblib
并行化一个 CPU 繁重的 for
循环,但我发现不是将每个工作进程分配给不同的核心,而是最终所有这些都被分配到同一个核心,并且没有性能提升。
这是一个非常简单的例子......
from joblib import Parallel,delayed
import numpy as np
def testfunc(data):
# some very boneheaded CPU work
for nn in xrange(1000):
for ii in data[0,:]:
for jj in data[1,:]:
ii*jj
def run(niter=10):
data = (np.random.randn(2,100) for ii in xrange(niter))
pool = Parallel(n_jobs=-1,verbose=1,pre_dispatch='all')
results = pool(delayed(testfunc)(dd) for dd in data)
if __name__ == '__main__':
run()
...这是我在运行此脚本时在 htop
中看到的内容:
我在 4 核笔记本电脑上运行 Ubuntu 12.10 (3.5.0-26)。显然 joblib.Parallel
正在为不同的工作人员生成单独的进程,但是有什么方法可以让这些进程在不同的内核上执行?
最佳答案
经过一番谷歌搜索后,我找到了答案 here .
事实证明,某些 Python 模块(numpy
、scipy
、tables
、pandas
、 skimage
...) 在导入时会影响核心亲和力。据我所知,这个问题似乎是由它们链接到多线程 OpenBLAS 库引起的。
一种解决方法是使用
重置任务关联性os.system("taskset -p 0xff %d" % os.getpid())
在模块导入后粘贴此行,我的示例现在可以在所有内核上运行:
到目前为止,我的经验是这似乎对 numpy
的性能没有任何负面影响,尽管这可能是特定于机器和任务的。
更新:
还有两种方法可以禁用 OpenBLAS 本身的 CPU 关联重置行为。在运行时,您可以使用环境变量 OPENBLAS_MAIN_FREE
(或 GOTOBLAS_MAIN_FREE
),例如
OPENBLAS_MAIN_FREE=1 python myscript.py
或者,如果您从源代码编译 OpenBLAS,您可以在构建时通过编辑 Makefile.rule
以包含该行来永久禁用它
NO_AFFINITY=1
关于python - 为什么我导入 numpy 后多处理只使用一个核心?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19528334/