2013-08-07 12 views
15

Próbuję uruchomić prosty test przy użyciu wieloprocesowości. Test działa dobrze, dopóki nie zaimportuję numpy (mimo że nie jest używany w programie). Oto kod:Wieloprocesorowość niekompatybilna z NumPy

from multiprocessing import Pool 
import time 
import numpy as np #this is the problematic line 


def CostlyFunc(N): 
    """""" 
    tstart = time.time() 
    x = 0 
    for i in xrange(N): 
     for j in xrange(N): 
      if i % 2: x += 2 
      else: x -= 2  
    print "CostlyFunc : elapsed time %f s" % (time.time() - tstart) 
    return x 

#serial application 
ResultList0 = [] 
StartTime = time.time() 
for i in xrange(3): 
    ResultList0.append(CostlyFunc(5000)) 
print "Elapsed time (serial) : ", time.time() - StartTime 


#multiprocessing application 
StartTime = time.time() 
pool = Pool() 
asyncResult = pool.map_async(CostlyFunc, [5000, 5000, 5000]) 
ResultList1 = asyncResult.get() 
print "Elapsed time (multiporcessing) : ", time.time() - StartTime 

Jeśli nie importować numpy wynik to:

CostlyFunc : elapsed time 2.866265 s 
CostlyFunc : elapsed time 2.793213 s 
CostlyFunc : elapsed time 2.794936 s 
Elapsed time (serial) : 8.45455098152 
CostlyFunc : elapsed time 2.889815 s 
CostlyFunc : elapsed time 2.891556 s 
CostlyFunc : elapsed time 2.898898 s 
Elapsed time (multiporcessing) : 2.91595196724 

Łączny czas, jaki upłynął, jest podobny do czasu wymaganego przez 1 procesu, co oznacza, że ​​obliczenia były zrównoleglone. Jeśli robię import numpy wynik staje:

CostlyFunc : elapsed time 2.877116 s 
CostlyFunc : elapsed time 2.866778 s 
CostlyFunc : elapsed time 2.860894 s 
Elapsed time (serial) : 8.60492110252 
CostlyFunc : elapsed time 8.450145 s 
CostlyFunc : elapsed time 8.473006 s 
CostlyFunc : elapsed time 8.506402 s 
Elapsed time (multiporcessing) : 8.55398178101 

Całkowity czas jaki upłynął jest taka sama dla obu metod szeregowych i wieloprocesorowych, ponieważ tylko jeden rdzeń jest używany. Jest oczywiste, że problem pochodzi od numpy. Czy jest możliwe, że mam niekompatybilność między moimi wersjami wieloprocesowymi a NumPy?

Obecnie używam Python2.7, NumPy 1.6.2 i wieloprocesorowe 0.70a1 na linux

+1

To bardzo dziwne - Wygląda na to, że działa dobrze na OSX z Pythonem 2.7 i NumPy 1.7. Od czasu wygląda na to, że trzy rdzenie są używane, ale czas przetwarzania jest spowolniony - czy możesz to potwierdzić? – Daniel

+0

Dziękuję za odpowiedź. Jestem pewien, że obliczenia są dokonywane tylko na 1 rdzeniu, gdy importuję NumPy (sprawdziłem przy pomocy mpstat (http://linuxcommand.org/man_pages/mpstat1.html)). Wygląda na to, że ten sam rdzeń oblicza 3 zadania w tym samym czasie: więc każde zadanie zajmuje ~ 8,5 sekundy, ale całkowity czas wynosi również ~ 8,5 sekundy. – user2660966

+0

Próbowałem z numpy 1.6.1, numpy 1.6.2 i numpy 1.7.1 ... ten sam problem – user2660966

Odpowiedz

2

(pierwszy post przepraszam, jeśli to nie jest dobrze sformułowany lub ustawioną równo)

można zatrzymać Numpy używać wielowątkowość przez seting MKL_NUM_THREADS do 1

w Debianie użyłem:

export MKL_NUM_THREADS=1 

Źródło z powiązanym stackoverflow postu: Python: How do you stop numpy from multithreading?

Wynik:

[email protected]:~/tmp$ python multi.py 
CostlyFunc : elapsed time 3.847009 s 
CostlyFunc : elapsed time 3.253226 s 
CostlyFunc : elapsed time 3.415734 s 
Elapsed time (serial) : 10.5163660049 
CostlyFunc : elapsed time 4.218424 s 
CostlyFunc : elapsed time 5.252429 s 
CostlyFunc : elapsed time 4.862513 s 
Elapsed time (multiporcessing) : 9.11713695526 

[email protected]:~/tmp$ export MKL_NUM_THREADS=1 

[email protected]:~/tmp$ python multi.py 
CostlyFunc : elapsed time 3.014677 s 
CostlyFunc : elapsed time 3.102548 s 
CostlyFunc : elapsed time 3.060915 s 
Elapsed time (serial) : 9.17840886116 
CostlyFunc : elapsed time 3.720322 s 
CostlyFunc : elapsed time 3.950583 s 
CostlyFunc : elapsed time 3.656165 s 
Elapsed time (multiporcessing) : 7.399310112 

Nie jestem pewien, czy to pomaga, bo myślę, że w końcu chcesz numpy biec równolegle może próbować dostosować liczbę wątków dla numpy do komputera.

+0

Do osoby, która przegłosowała: jeśli głosujesz - wyjaśnij dlaczego i zadawaj pytania w sekcji komentarzy. – Jon

1

Z uwagi na swoje pytanie, rzucić okiem na ten link @Ophion nie, ale mam oznaczone jako duplikat Why does multiprocessing use only a single core after I import numpy? - ali_m Sie 22 na 9:06

chciałbym sprawdzić, czy używasz zoptymalizowanej wersji BLAS. Odkryłem, że niektóre ogólne instalacje numpy nie dostarczają i nie optymalizują wersji tej biblioteki. Z mojej instalacji można zauważyć, że to wskazuje na libf77blas.so, libcblas.so, libatlas.so.

Oto instrukcje do budowy zoptymalizowanej wersji Blas: http://docs.scipy.org/doc/numpy/user/install.html

Od zw Pythona:

import numpy.core._dotblas

>>> numpy.core._dotblas.__file__ 

## output: 

'PYTHONHOME/lib/python2.7/site-packages/numpy/core/_dotblas.so' 

Od terminalu:

$ ldd 'PYTHONHOME/lib/python2.7/site-packages/numpy/core/_dotblas.so' 
linux-vdso.so.1 => (0x00007fff241ff000) 
libf77blas.so => /opt/arch/intel/lib/libf77blas.so (0x00007f6050647000) 
libcblas.so => /opt/arch/intel/lib/libcblas.so (0x00007f6050429000) 
libatlas.so => /opt/arch/intel/lib/libatlas.so (0x00007f604fbf1000) 
libpython2.7.so.1.0 => 'PYTHONHOME/lib/libpython2.7.so.1.0 (0x00007f604f817000) 
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f604f5f9000) 
libc.so.6 => /lib64/libc.so.6 (0x00007f604f266000) 
libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007f604ef74000) 
libm.so.6 => /lib64/libm.so.6 (0x00007f604ecef000) 
libdl.so.2 => /lib64/libdl.so.2 (0x00007f604eaeb000) 
libutil.so.1 => /lib64/libutil.so.1 (0x00007f604e8e8000) 

/lib64/ld-linux-x86-64.so.2 (0x0000003c75e00000)