Strano bug in Panda e Numpy per quanto riguarda il multithreading

La maggior parte della funzione di Numpy abiliterà il multithreading per impostazione predefinita.

ad esempio, lavoro su una stazione di lavoro Intel a 8 core, se eseguo uno script

import numpy as np    
x=np.random.random(1000000)
for i in range(100000):
    np.sqrt(x)

Linux topmostrerà un utilizzo della CPU dell'800% durante l'esecuzione come il che significa che numpy rileva automaticamente che la mia workstation ha 8 core e np.sqrtusa automaticamente tutti e 8 i core per accelerare il calcolo.

Tuttavia, ho trovato un bug strano. Se eseguo uno script

import numpy as np
import pandas as pd
df=pd.DataFrame(np.random.random((10,10)))
df+df
x=np.random.random(1000000)
for i in range(100000):
    np.sqrt(x)

l'utilizzo della cpu è del 100% !!. Significa che se si aggiungono due Panda DataFrame prima di eseguire qualsiasi funzione numpy, la funzione di multithreading automatico di numpy scompare senza alcun preavviso! Questo non è assolutamente ragionevole, perché il calcolo di Pandas dataFrame influirebbe sull'impostazione del thread Numpy? E 'un errore? Come aggirare questo?

PS:

Scavo ulteriormente usando lo perfstrumento Linux .

eseguendo i primi spettacoli di script

Durante l'esecuzione del secondo script mostra

Quindi entrambi gli script coinvolgono libmkl_vml_avx2.so, mentre il primo script prevede ulteriori libiomp5.soche sembrano essere correlati a openMP.

E poiché vml significa libreria matematica vettoriale Intel, quindi secondo il documento vml immagino che almeno le funzioni seguenti siano tutte automaticamente multithread

Pandas usa numexprsotto il cofano per calcolare alcune operazioni e numexprimposta il numero massimo di thread per vml su 1, quando viene importato :

# The default for VML is 1 thread (see #39)
set_vml_num_threads(1)

e viene importato dai panda quando df+dfviene valutato in expressions.py :

from pandas.core.computation.check import _NUMEXPR_INSTALLED

if _NUMEXPR_INSTALLED:
   import numexpr as ne

Tuttavia, la distribuzione Anaconda utilizza anche VML-funzionalità per funzioni quali sqrt, sin, cose così via - e una volta numexprimpostare il numero massimo di VML-thread per 1, le funzioni NumPy uso più parallelizzazione.

Il problema può essere facilmente visto in gdb (usando lo script lento):

>>> gdb --args python slow.py
(gdb) b mkl_serv_domain_set_num_threads
function "mkl_serv_domain_set_num_threads" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (mkl_serv_domain_set_num_threads) pending.
(gbd) run
Thread 1 "python" hit Breakpoint 1, 0x00007fffee65cd70 in mkl_serv_domain_set_num_threads () from /home/ed/anaconda37/lib/python3.7/site-packages/numpy/../../../libmkl_intel_thread.so
(gdb) bt 
#0  0x00007fffee65cd70 in mkl_serv_domain_set_num_threads () from /home/ed/anaconda37/lib/python3.7/site-packages/numpy/../../../libmkl_intel_thread.so
#1  0x00007fffe978026c in _set_vml_num_threads(_object*, _object*) () from /home/ed/anaconda37/lib/python3.7/site-packages/numexpr/interpreter.cpython-37m-x86_64-linux-gnu.so
#2  0x00005555556cd660 in _PyMethodDef_RawFastCallKeywords () at /tmp/build/80754af9/python_1553721932202/work/Objects/call.c:694
...
(gdb) print $rdi
$1 = 1

cioè possiamo vedere, numexprimposta il numero di thread su 1. Che viene successivamente usato quando viene chiamata la funzione vml-sqrt:

(gbd) b mkl_serv_domain_get_max_threads
Breakpoint 2 at 0x7fffee65a900
(gdb) (gdb) c
Continuing.

Thread 1 "python" hit Breakpoint 2, 0x00007fffee65a900 in mkl_serv_domain_get_max_threads () from /home/ed/anaconda37/lib/python3.7/site-packages/numpy/../../../libmkl_intel_thread.so
(gdb) bt
#0  0x00007fffee65a900 in mkl_serv_domain_get_max_threads () from /home/ed/anaconda37/lib/python3.7/site-packages/numpy/../../../libmkl_intel_thread.so
#1  0x00007ffff01fcea9 in mkl_vml_serv_threader_d_1i_1o () from /home/ed/anaconda37/lib/python3.7/site-packages/numpy/../../../libmkl_intel_thread.so
#2  0x00007fffedf78563 in vdSqrt () from /home/ed/anaconda37/lib/python3.7/site-packages/numpy/../../../libmkl_intel_lp64.so
#3  0x00007ffff5ac04ac in trivial_two_operand_loop () from /home/ed/anaconda37/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so

Quindi possiamo vedere che numpy usa l'implementazione di vml vdSqrtche utilizza mkl_vml_serv_threader_d_1i_1oper decidere se il calcolo deve essere fatto in parallelo e sembra il numero di thread:

(gdb) fin
Run till exit from #0  0x00007fffee65a900 in mkl_serv_domain_get_max_threads () from /home/ed/anaconda37/lib/python3.7/site-packages/numpy/../../../libmkl_intel_thread.so
0x00007ffff01fcea9 in mkl_vml_serv_threader_d_1i_1o () from /home/ed/anaconda37/lib/python3.7/site-packages/numpy/../../../libmkl_intel_thread.so
(gdb) print $rax
$2 = 1

il registro %raxha il numero massimo di thread ed è 1.

Ora possiamo usare numexprper aumentare il numero di thread vml , ovvero:

import numpy as np
import numexpr as ne
import pandas as pd
df=pd.DataFrame(np.random.random((10,10)))
df+df

#HERE: reset number of vml-threads
ne.set_vml_num_threads(8)

x=np.random.random(1000000)
for i in range(10000):
    np.sqrt(x)     # now in parallel

Ora vengono utilizzati più core!

Guardando intontito, sembra che sotto il cofano abbia avuto problemi di attivazione / disattivazione con il multithreading e, a seconda della versione che stai utilizzando, potresti aspettarti di iniziare a vedere arresti anomali quando urti ne.set_vml_num_threads () ..

http://numpy-discussion.10968.n7.nabble.com/ANN-NumExpr-2-7-0-Release-td47414.html

Ho bisogno di capire come questo è incollato all'interprete Python, dato il tuo esempio di codice in cui sembra in qualche modo consentire più chiamate apparentemente sincrone / ordinate a np.sqrt () di procedere in parallelo. Immagino che se l'interprete di Python restituisce sempre un riferimento a un oggetto quando fa scoppiare lo stack, e nel tuo esempio sta semplicemente lanciando quei riferimenti e non assegnandoli o manipolandoli in alcun modo andrebbe bene. Ma se le iterazioni di loop successive dipendono dalle precedenti, allora sembra meno chiaro come queste possano essere parallelizzate in modo sicuro. Probabilmente un fallimento silenzioso / risultati errati sono un risultato peggiore degli arresti anomali.

Penso che la tua premessa iniziale possa essere errata -

Hai dichiarato: il che significa che numpy rileva automaticamente che la mia workstation ha 8 core e np.sqrt utilizza automaticamente tutti e 8 i core per accelerare il calcolo.

Una singola funzione np.sqrt () non può indovinare come verrà successivamente invocata o restituita prima che sia stata parzialmente completata. Ci sono meccanismi di parallelismo in Python, ma nessuno è automatico.

Ora, detto questo, l'interprete di Python potrebbe essere in grado di ottimizzare il ciclo for per il parallelismo, che potrebbe essere quello che stai vedendo, ma sospetto fortemente che se guardi il tempo dell'orologio a muro per l'esecuzione di questo loop sarà no diverso indipendentemente dal fatto che (apparentemente) utilizzi 8 core o 1 core.

AGGIORNAMENTO: Dopo aver letto un po 'più di commenti sembra che il comportamento multi-core che stai vedendo sia correlato alla distribuzione anaconda dell'interprete Python. Ho dato un'occhiata ma non sono riuscito a trovare alcun codice sorgente per esso, ma sembra che la licenza Python consenta alle entità (come anaconda.com) di compilare e distribuire derivati ​​dell'interprete senza richiedere la pubblicazione delle loro modifiche.

Immagino che tu possa contattare la gente dell'anaconda: il comportamento che stai vedendo sarà difficile da capire senza sapere cosa / se qualcosa è cambiato nell'interprete ..

Fai anche un rapido controllo dell'orologio a muro con / senza l'ottimizzazione per vedere se è effettivamente 8 volte più veloce - anche se hai davvero tutti gli 8 core funzionanti invece di 1 sarebbe bene sapere se i risultati sono effettivamente 8x più veloce o se ci sono spinlock in uso che stanno ancora serializzando su un singolo mutex.