为什么在导入numpy后多处理只使用一个核心？

Question

我不确定这是否更像是一个操作系统问题,但我想我会问这里,以防任何人从Python的结尾有一些见解.

我一直在尝试使用一个CPU密集型for循环joblib,但是我发现不是将每个工作进程分配给不同的核心,我最终将它们全部分配到同一个核心而没有性能提升.

这是一个非常简单的例子......

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是为不同的工作者生成单独的进程,但有没有办法让这些进程在不同的内核上执行？

Answer 1

经过一些谷歌上搜索我找到了答案在这里.

事实证明,某些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

Answer 2

Python 3现在公开了直接设置关联的方法

>>> import os
>>> os.sched_getaffinity(0)
{0, 1, 2, 3}
>>> os.sched_setaffinity(0, {1, 3})
>>> os.sched_getaffinity(0)
{1, 3}
>>> x = {i for i in range(10)}
>>> x
{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
>>> os.sched_setaffinity(0, x)
>>> os.sched_getaffinity(0)
{0, 1, 2, 3}

Answer 3

这似乎是Ubuntu上Python的常见问题,并不特定于joblib:

• 从Ubuntu 10.10升级到12.04后,multiprocessing.map和joblib只使用1个cpu
• Python多处理仅使用一个核心
• multiprocessing.Pool进程锁定到单个核心

我建议尝试使用CPU affinity(taskset).