Dlaczego wieloprocesorowość używa tylko jednego rdzenia po zaimportowaniu numpy?

Nie jestem pewien, czy liczy się to bardziej jako problem z systemem operacyjnym, ale pomyślałem, że zapytałbym tutaj, gdyby ktoś miał jakiś wgląd w Python.

Próbowałem zsynchronizować forpętlę obciążającą procesor joblib, ale stwierdziłem, że zamiast przypisywać każdy proces roboczy do innego rdzenia, w końcu wszystkie są przypisane do tego samego rdzenia i nie ma wzrostu wydajności.

Oto bardzo trywialny przykład ...

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()

... a oto, co widzę htoppodczas działania tego skryptu:

Używam Ubuntu 12.10 (3.5.0-26) na laptopie z 4 rdzeniami. Jasne joblib.Paralleljest, że powstają oddzielne procesy dla różnych procesów roboczych, ale czy istnieje sposób, aby te procesy były wykonywane na różnych rdzeniach?

Po kilku kolejnych googlach znalazłem odpowiedź tutaj .

Okazuje się, że niektóre moduły Pythona ( numpy, scipy, tables, pandas, skimage...) bałagan z rdzeniem powinowactwa na import. O ile wiem, problem ten wydaje się być spowodowany przez ich łączenie z wielowątkowymi bibliotekami OpenBLAS.

Obejściem problemu jest zresetowanie koligacji zadania za pomocą

os.system("taskset -p 0xff %d" % os.getpid())

Po wklejeniu tej linii po zaimportowaniu modułu mój przykład działa teraz na wszystkich rdzeniach:

Z mojego dotychczasowego doświadczenia wynika, że ​​nie wydaje się to mieć żadnego negatywnego wpływu na numpywydajność, chociaż jest to prawdopodobnie zależne od maszyny i zadania.

Aktualizacja:

Istnieją również dwa sposoby, aby wyłączyć resetowanie powinowactwa procesora samego OpenBLAS. W czasie wykonywania możesz na przykład użyć zmiennej środowiskowej OPENBLAS_MAIN_FREE(lub GOTOBLAS_MAIN_FREE)

OPENBLAS_MAIN_FREE=1 python myscript.py

Lub alternatywnie, jeśli kompilujesz OpenBLAS ze źródła, możesz go trwale wyłączyć w czasie kompilacji, edytując tak, Makefile.ruleaby zawierał wiersz

NO_AFFINITY=1

Python 3 udostępnia teraz metody do bezpośredniego ustawiania koligacji

>>> 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}

Wydaje się, że jest to częsty problem z Pythonem w systemie Ubuntu i nie dotyczy joblib:

• Zarówno multiprocessing.map, jak i joblib używają tylko 1 procesora po aktualizacji z Ubuntu 10.10 do 12.04
• Wieloprocesorowość Pythona wykorzystuje tylko jeden rdzeń
• Procesy puli zamknięte w jednym rdzeniu

Sugerowałbym eksperymentowanie z koligacją procesora (taskset ).