为什么我导入numpy后，多处理只使用了一个内核？
我不确定这是否更多地算作是操作系统问题，但我想我应该在这里问一下，以防有人从Python end of things中获得一些见解。
我一直在尝试使用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()...and下面是我在运行此脚本时在htop中看到的内容：
我在一台4核笔记本电脑上运行Ubuntu 12.10 (3.5.0-26)。显然，joblib.Parallel正在为不同的工作进程产生单独的进程，但是有没有什么方法可以让这些进程在不同的内核上执行？
回答 2
Stack Overflow用户
发布于 2013-03-26 23:36:46
经过更多的谷歌搜索，我找到了答案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=1Stack Overflow用户
发布于 2015-07-13 01:56:28
Python3现在公开methods以直接设置亲和性
>>> 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}https://stackoverflow.com/questions/15639779
复制相似问题