Perché il multiprocessing utilizza solo un singolo core dopo aver importato numpy?

Non sono sicuro che ciò valga di più come un problema del sistema operativo, ma ho pensato di chiedere qui nel caso in cui qualcuno abbia qualche intuizione dalla fine delle cose di Python.

Ho provato a parallelizzare un forloop pesante per CPU usando joblib, ma trovo che invece di ogni processo di lavoro assegnato a un core diverso, finisco con tutti loro assegnati allo stesso core e nessun guadagno in termini di prestazioni.

Ecco un esempio molto banale ...

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

... ed ecco cosa vedo htopmentre questo script è in esecuzione:

Sto eseguendo Ubuntu 12.10 (3.5.0-26) su un laptop con 4 core. Chiaramente joblib.Parallelsta generando processi separati per i diversi lavoratori, ma c'è un modo in cui posso fare eseguire questi processi su core diversi?

Dopo qualche altro google ho trovato la risposta qui .

Risulta che alcuni moduli Python ( numpy, scipy, tables, pandas, skimage...) confusione con affinità nucleo importazione. Per quanto ne so, questo problema sembra essere stato causato in modo specifico dal loro collegamento con le librerie OpenBLAS multithread.

Una soluzione alternativa consiste nel ripristinare l'affinità dell'attività mediante

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

Con questa riga incollata dopo l'importazione del modulo, il mio esempio ora funziona su tutti i core:

Finora la mia esperienza è stata che questo non sembra avere alcun effetto negativo sulle numpyprestazioni, sebbene questo sia probabilmente specifico per macchina e compito.

Aggiornare:

Esistono anche due modi per disabilitare il comportamento di ripristino dell'affinità della CPU di OpenBLAS stesso. In fase di esecuzione è possibile utilizzare la variabile di ambiente OPENBLAS_MAIN_FREE(o GOTOBLAS_MAIN_FREE), ad esempio

OPENBLAS_MAIN_FREE=1 python myscript.py

In alternativa, se stai compilando OpenBLAS dal sorgente puoi disabilitarlo permanentemente in fase di compilazione modificando il file Makefile.ruleper contenere la riga

NO_AFFINITY=1

Python 3 ora espone i metodi per impostare direttamente l'affinità

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

Questo sembra essere un problema comune con Python su Ubuntu e non è specifico per joblib:

• Sia multiprocessing.map che joblib utilizzano solo 1 cpu dopo l'aggiornamento da Ubuntu 10.10 a 12.04
• Il multiprocessing di Python utilizza solo un core
• multiprocessing.Pool processi bloccati su un singolo core

Suggerirei di sperimentare l'affinità della CPU ( taskset).