Benchmarking (Python vs. C ++ przy użyciu BLAS) i (numpy)

Chciałbym napisać program, który w szerokim zakresie wykorzystuje funkcje algebry liniowej BLAS i LAPACK. Ponieważ wydajność jest problemem, przeprowadziłem testy porównawcze i chciałbym wiedzieć, czy zastosowane przeze mnie podejście jest uzasadnione.

Mam, że tak powiem, trzech zawodników i chcę sprawdzić ich wyniki za pomocą prostego mnożenia macierzy. Zawodnicy to:

1. Numpy, wykorzystując tylko funkcjonalność dot.
2. Python, wywołujący funkcje BLAS-a poprzez wspólny obiekt.
3. C ++, wywołując funkcje BLAS-a poprzez wspólny obiekt.

Scenariusz

Zaimplementowałem mnożenie macierzy dla różnych wymiarów i. ibiegnie od 5 do 500 z przyrostem 5 i matricies m1i m2są ustawione w następujący sposób:

m1 = numpy.random.rand(i,i).astype(numpy.float32)
m2 = numpy.random.rand(i,i).astype(numpy.float32)

1. Odrętwiały

Użyty kod wygląda następująco:

tNumpy = timeit.Timer("numpy.dot(m1, m2)", "import numpy; from __main__ import m1, m2")
rNumpy.append((i, tNumpy.repeat(20, 1)))

2. Python, wywołujący BLAS przez wspólny obiekt

Dzięki funkcji

_blaslib = ctypes.cdll.LoadLibrary("libblas.so")
def Mul(m1, m2, i, r):

    no_trans = c_char("n")
    n = c_int(i)
    one = c_float(1.0)
    zero = c_float(0.0)

    _blaslib.sgemm_(byref(no_trans), byref(no_trans), byref(n), byref(n), byref(n), 
            byref(one), m1.ctypes.data_as(ctypes.c_void_p), byref(n), 
            m2.ctypes.data_as(ctypes.c_void_p), byref(n), byref(zero), 
            r.ctypes.data_as(ctypes.c_void_p), byref(n))

kod testu wygląda następująco:

r = numpy.zeros((i,i), numpy.float32)
tBlas = timeit.Timer("Mul(m1, m2, i, r)", "import numpy; from __main__ import i, m1, m2, r, Mul")
rBlas.append((i, tBlas.repeat(20, 1)))

3. c ++, wywołując BLAS za pośrednictwem udostępnionego obiektu

Teraz kod c ++ jest oczywiście trochę dłuższy, więc ograniczam informacje do minimum.
Ładuję funkcję z

void* handle = dlopen("libblas.so", RTLD_LAZY);
void* Func = dlsym(handle, "sgemm_");

Czas mierzę w gettimeofdayten sposób:

gettimeofday(&start, NULL);
f(&no_trans, &no_trans, &dim, &dim, &dim, &one, A, &dim, B, &dim, &zero, Return, &dim);
gettimeofday(&end, NULL);
dTimes[j] = CalcTime(start, end);

gdzie jjest pętla działająca 20 razy. Obliczam upływający czas

double CalcTime(timeval start, timeval end)
{
double factor = 1000000;
return (((double)end.tv_sec) * factor + ((double)end.tv_usec) - (((double)start.tv_sec) * factor + ((double)start.tv_usec))) / factor;
}

Wyniki

Wynik przedstawiono na poniższym wykresie:

pytania

1. Czy uważasz, że moje podejście jest sprawiedliwe, czy też są jakieś niepotrzebne koszty ogólne, których mogę uniknąć?
2. Czy spodziewałbyś się, że wynik pokaże tak dużą rozbieżność między podejściem C ++ i Python? Obaj używają obiektów współdzielonych do swoich obliczeń.
3. Ponieważ wolałbym używać języka Python w moim programie, co mogę zrobić, aby zwiększyć wydajność podczas wywoływania procedur BLAS lub LAPACK?

Pobieranie

Pełny test porównawczy można pobrać tutaj . (JF Sebastian umożliwił ten link ^^)

Sprawdziłem twój punkt odniesienia . Na moim komputerze nie ma różnicy między C ++ a numpy:

Czy uważasz, że moje podejście jest sprawiedliwe, czy też są jakieś niepotrzebne koszty ogólne, których mogę uniknąć?

Wydaje się to sprawiedliwe, ponieważ nie ma różnicy w wynikach.

Czy spodziewałbyś się, że wynik pokaże tak dużą rozbieżność między podejściem C ++ i Python? Obaj używają obiektów współdzielonych do swoich obliczeń.

Nie.

Ponieważ wolałbym używać języka Python w moim programie, co mogę zrobić, aby zwiększyć wydajność podczas wywoływania procedur BLAS lub LAPACK?

Upewnij się, że numpy używa zoptymalizowanej wersji bibliotek BLAS / LAPACK w twoim systemie.

AKTUALIZACJA (30.07.2014):

Ponownie przeprowadziłem test porównawczy na naszym nowym HPC. Zarówno sprzęt, jak i stos oprogramowania zmieniły się w porównaniu z konfiguracją w oryginalnej odpowiedzi.

Wyniki umieściłem w arkuszu kalkulacyjnym Google (zawiera również wyniki z oryginalnej odpowiedzi).

Sprzęt komputerowy

Nasz HPC ma dwa różne węzły, jeden z procesorami Intel Sandy Bridge, a drugi z nowszymi procesorami Ivy Bridge:

Sandy (MKL, OpenBLAS, ATLAS):

• Procesor : 2 x 16 Intel (R) Xeon (R) E2560 Sandy Bridge @ 2,00 GHz (16 rdzeni)
• RAM : 64 GB

Bluszcz (MKL, OpenBLAS, ATLAS):

• Procesor : 2 x 20 Intel (R) Xeon (R) E2680 V2 Ivy Bridge @ 2,80 GHz (20 rdzeni, z HT = 40 rdzeni)
• RAM : 256 GB

Oprogramowanie

Stos oprogramowania jest dla obu węzłów sam. Zamiast GotoBLAS2 , OpenBLAS jest używany i jest również wielowątkowy ATLAS BLAS, która jest ustawiona do 8 nici (stałe).

• OS : Suse
• Kompilator Intel : ictce-5.3.0
• Numpy: 1.8.0
• OpenBLAS: 0.2.6
• ATLAS :: 3.8.4

Benchmark produktów dot

Kod porównawczy jest taki sam jak poniżej. Jednak dla nowych maszyn przeprowadziłem również benchmark dla rozmiarów matryc 5000 i 8000 .
Poniższa tabela zawiera wyniki testu porównawczego z oryginalnej odpowiedzi (nazwa zmieniona: MKL -> Nehalem MKL, Netlib Blas -> Nehalem Netlib BLAS itp.)

Wydajność jednowątkowa:

Wydajność wielowątkowa (8 wątków):

Wątki a rozmiar matrycy (Ivy Bridge MKL) :

Pakiet Benchmark

Wydajność jednowątkowa:

Wydajność wielowątkowa (8 wątków):

Wniosek

Nowe wyniki testu porównawczego są podobne do tych w oryginalnej odpowiedzi. OpenBLAS i MKL działają na tym samym poziomie, z wyjątkiem testu wartości własnej . Test wartości własnej działa dość dobrze na OpenBLAS w trybie jednowątkowym . W trybie wielowątkowym wydajność jest gorsza.

„Rozmiar matrycy vs nici wykres” wskazują także, że chociaż MKL jak OpenBLAS ogólnie skalę oraz z liczbą rdzeni / wątków, zależy od rozmiaru macierzy. W przypadku małych matryc dodanie większej liczby rdzeni nie poprawi zbytnio wydajności.

Występuje również około 30% wzrost wydajności z Sandy Bridge do Ivy Bridge, co może być spowodowane wyższą częstotliwością zegara (+ 0,8 Ghz) i / lub lepszą architekturą.

Oryginalna odpowiedź (04.10.2011):

Jakiś czas temu musiałem zoptymalizować niektóre obliczenia / algorytmy algebry liniowej, które zostały napisane w Pythonie przy użyciu numpy i BLAS, więc przetestowałem / przetestowałem różne konfiguracje numpy / BLAS.

Konkretnie przetestowałem:

• Odrętwiały z ATLASEM
• Numpy z GotoBlas2 (1.13)
• Numpy z MKL (11.1 / 073)
• Numpy z Accelerate Framework (Mac OS X)

Przeprowadziłem dwa różne testy porównawcze:

1. prosty iloczyn skalarny macierzy o różnych rozmiarach
2. Pakiet Benchmark, który można znaleźć tutaj .

Oto moje wyniki:

Maszyny

Linux (MKL, ATLAS, No-MKL, GotoBlas2):

• System operacyjny : Ubuntu Lucid 10.4 64-bitowy.
• Procesor : 2 x 4 Intel (R) Xeon (R) E5504 @ 2,00 GHz (8 rdzeni)
• RAM : 24 GB
• Kompilator Intel : 11.1 / 073
• Scipy : 0,8
• Numpy : 1,5

Mac Book Pro (Accelerate Framework):

• System operacyjny : Mac OS X Snow Leopard (10.6)
• Procesor : 1 Intel Core 2 Duo 2,93 Ghz (2 rdzenie)
• RAM : 4 GB
• Scipy : 0,7
• Numpy : 1.3

Mac Server (Accelerate Framework):

• System operacyjny : Mac OS X Snow Leopard Server (10.6)
• Procesor : 4 X Intel (R) Xeon (R) E5520 @ 2,26 GHz (8 rdzeni)
• RAM : 4 GB
• Scipy : 0,8
• Numpy : 1.5.1

Benchmark produktowy

Kod :

import numpy as np
a = np.random.random_sample((size,size))
b = np.random.random_sample((size,size))
%timeit np.dot(a,b)

Wyniki :

    System | rozmiar = 1000 | rozmiar = 2000 | rozmiar = 3000 |
netlib BLAS | 1350 ms | 10900 ms | 39200 ms |    
ATLAS (1 procesor) | 314 ms | 2560 ms | 8700 ms |     
MKL (1 procesory) | 268 ms | 2110 ms | 7120 ms |
MKL (2 procesory) | - | - | 3660 ms |
MKL (8 procesorów) | 39 ms | 319 ms | 1000 ms |
GotoBlas2 (1 procesor) | 266 ms | 2100 ms | 7280 ms |
GotoBlas2 (2 procesory) | 139 ms | 1009 ms | 3690 ms |
GotoBlas2 (8 procesorów) | 54 ms | 389 ms | 1250 ms |
Mac OS X (1 procesor) | 143 ms | 1060 ms | 3605 ms |
Serwer Mac (1 procesor) | 92 ms | 714 ms | 2130 ms |

Pakiet Benchmark

Kod :
Aby uzyskać dodatkowe informacje na temat zestawu testów, zobacz tutaj .

Wyniki :

    System | wartości własne | svd | det | inv | kropka |
netlib BLAS | 1688 ms | 13102 ms | 438 ms | 2155 ms | 3522 ms |
ATLAS (1 procesor) | 1210 ms | 5897 ms | 170 ms | 560 ms | 893 ms |
MKL (1 procesory) | 691 ms | 4475 ms | 141 ms | 450 ms | 736 ms |
MKL (2 procesory) | 552 ms | 2718 ms | 96 ms | 267 ms | 423 ms |
MKL (8 procesorów) | 525 ms | 1679 ms | 60 ms | 137 ms | 197 ms |  
GotoBlas2 (1 procesor) | 2124 ms | 4636 ms | 147 ms | 456 ms | 743 ms |
GotoBlas2 (2 procesory) | 1560 ms | 3278 ms | 116 ms | 295 ms | 460 ms |
GotoBlas2 (8 procesorów) | 741 ms | 2914 ms | 82 ms | 262 ms | 192 ms |
Mac OS X (1 procesor) | 948 ms | 4339 ms | 151 ms | 318 ms | 566 ms |
Serwer Mac (1 procesor) | 1033 ms | 3645 ms | 99 ms | 232 ms | 342 ms |

Instalacja

Instalacja MKL obejmowała instalację kompletnego pakietu Intel Compiler Suite, co jest dość proste. Jednak z powodu pewnych błędów / problemów konfiguracja i kompilacja numpy z obsługą MKL była trochę kłopotliwa.

GotoBlas2 to mały pakiet, który można łatwo skompilować jako bibliotekę współdzieloną. Jednak z powodu błędu musisz ponownie utworzyć współdzieloną bibliotekę po jej zbudowaniu, aby móc jej używać z numpy.
Oprócz tego budowania go dla wielu platform docelowych nie działał z jakiegoś powodu. Musiałem więc utworzyć plik .so dla każdej platformy, dla której chcę mieć zoptymalizowany plik libgoto2.so .

Jeśli zainstalujesz numpy z repozytorium Ubuntu, automatycznie zainstaluje i skonfiguruje numpy do korzystania z ATLAS . Instalacja ATLAS ze źródła może zająć trochę czasu i wymaga dodatkowych czynności (fortran itp.).

Jeśli zainstalujesz numpy na komputerze z systemem Mac OS X z portami Fink lub Mac , skonfiguruje on numpy do korzystania z ATLAS lub Accelerate Framework firmy Apple . Możesz to sprawdzić, uruchamiając ldd na pliku numpy.core._dotblas lub wywołując numpy.show_config () .

Wnioski

MKL działa najlepiej, tuż za nim znajduje się GotoBlas2 .
W teście wartości własnej GotoBlas2 działa zaskakująco gorzej niż oczekiwano. Nie wiem, dlaczego tak jest.
Accelerate Framework firmy Apple działa naprawdę dobrze, szczególnie w trybie jednowątkowym (w porównaniu z innymi implementacjami BLAS).

Zarówno GotoBlas2, jak i MKL bardzo dobrze skalują się z liczbą wątków. Więc jeśli masz do czynienia z dużymi matrycami, uruchamianie go na wielu wątkach bardzo pomoże.

W każdym razie nie używaj domyślnej implementacji blas Netlib, ponieważ jest ona zbyt wolna, aby wykonać jakąkolwiek poważną pracę obliczeniową.

Na naszym klastrze zainstalowałem również ACML AMD, a wydajność była podobna do MKL i GotoBlas2 . Nie mam żadnych trudnych liczb.

Osobiście poleciłbym użycie GotoBlas2, ponieważ jest łatwiejszy w instalacji i jest darmowy.

Jeśli chcesz kodować w C ++ / C, sprawdź również Eigen3, który w niektórych przypadkach ma przewyższać MKL / GotoBlas2 i jest również dość łatwy w użyciu.

Oto kolejny test porównawczy (w systemie Linux wystarczy wpisać make): http://dl.dropbox.com/u/5453551/blas_call_benchmark.zip

http://dl.dropbox.com/u/5453551/blas_call_benchmark.png

Nie widzę zasadniczo żadnej różnicy między różnymi metodami dla dużych macierzy, między Numpy, Ctypes i Fortran. (Fortran zamiast C ++ --- i jeśli to ma znaczenie, Twój test porównawczy jest prawdopodobnie uszkodzony).

Twoja CalcTimefunkcja w C ++ wydaje się mieć błąd znaku. ... + ((double)start.tv_usec))powinno być zamiast tego ... - ((double)start.tv_usec)). Być może twój test porównawczy ma również inne błędy, np. Porównywanie różnych bibliotek BLAS lub różnych ustawień BLAS, takich jak liczba wątków lub między czasem rzeczywistym a czasem procesora?

EDYCJA : nie udało się policzyć nawiasów klamrowych w CalcTimefunkcji - jest OK.

Wskazówka: jeśli wykonujesz test porównawczy, zawsze umieszczaj gdzieś cały kod. Komentowanie benchmarków, zwłaszcza gdy są zaskakujące, bez pełnego kodu zwykle nie jest produktywne.

Aby dowiedzieć się, z którym BLAS Numpy jest połączony, wykonaj:

$ python
Python 2.7.2+ (domyślnie, 16 sierpnia 2011, 07:24:41) 
[GCC 4.6.1] w systemie linux2
Wpisz „pomoc”, „prawa autorskie”, „autorstwo” lub „licencja”, aby uzyskać więcej informacji.
>>> import numpy.core._dotblas
>>> numpy.core._dotblas .__ plik__
„/usr/lib/pymodules/python2.7/numpy/core/_dotblas.so”
>>> 
$ ldd /usr/lib/pymodules/python2.7/numpy/core/_dotblas.so
    linux-vdso.so.1 => (0x00007fff5ebff000)
    libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007fbe618b3000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbe61514000)

AKTUALIZACJA : Jeśli nie możesz zaimportować numpy.core._dotblas, Twój Numpy używa wewnętrznej kopii zapasowej BLAS, która jest wolniejsza i nie jest przeznaczona do obliczeń wydajnościowych! Odpowiedź od @Woltan poniżej wskazuje, że jest to wyjaśnienie różnicy, którą widzi w Numpy vs. Ctypes + BLAS.

Aby naprawić sytuację, potrzebujesz ATLAS lub MKL --- sprawdź te instrukcje: http://scipy.org/Installing_SciPy/Linux Większość dystrybucji Linuksa jest dostarczana z ATLAS, więc najlepszą opcją jest zainstalowanie ich libatlas-devpakietu (nazwa może się różnić) .

Biorąc pod uwagę rygor, jaki wykazałeś w swojej analizie, jestem zaskoczony dotychczasowymi wynikami. Postawiłem to jako „odpowiedź”, ale tylko dlatego, że jest zbyt długa na komentarz i daje taką możliwość (choć spodziewam się, że to rozważyłeś).

Pomyślałbym, że podejście numpy / python nie zwiększyłoby dużo narzutu dla macierzy o rozsądnej złożoności, ponieważ wraz ze wzrostem złożoności proporcja, w której uczestniczy python, powinna być niewielka. Bardziej interesują mnie wyniki po prawej stronie wykresu, ale pokazane tam rozbieżności rzędu wielkości byłyby niepokojące.

Zastanawiam się, czy używasz najlepszych algorytmów, z których może skorzystać Numpy. Z przewodnika po kompilacji dla systemu Linux:

„Build FFTW (3.1.2): SciPy Versions> = 0.7 and Numpy> = 1.2: Ze względu na problemy z licencją, konfiguracją i konserwacją usunięto obsługę FFTW w wersjach SciPy> = 0.7 i NumPy> = 1.2. Zamiast tego używa wbudowana wersja fftpack. Istnieje kilka sposobów, aby skorzystać z szybkości FFTW, jeśli jest to konieczne do przeprowadzenia analizy. Przejdź na wersję Numpy / Scipy, która obejmuje obsługę. Zainstaluj lub utwórz własne opakowanie FFTW. Zobacz http: //developer.berlios.de/projects/pyfftw/ jako niezatwierdzony przykład ”.

Czy skompilowałeś numpy z mkl? ( http://software.intel.com/en-us/articles/intel-mkl/ ). Jeśli używasz Linuksa, instrukcje kompilacji numpy z mkl są tutaj: http://www.scipy.org/Installing_SciPy/Linux#head-7ce43956a69ec51c6f2cedd894a4715d5bfff974 (pomimo adresu URL). Kluczową częścią jest:

[mkl]
library_dirs = /opt/intel/composer_xe_2011_sp1.6.233/mkl/lib/intel64
include_dirs = /opt/intel/composer_xe_2011_sp1.6.233/mkl/include
mkl_libs = mkl_intel_lp64,mkl_intel_thread,mkl_core 

Jeśli korzystasz z systemu Windows, możesz pobrać skompilowany plik binarny za pomocą mkl (a także uzyskać pyfftw i wiele innych powiązanych algorytmów) pod adresem : http://www.lfd.uci.edu/~gohlke/pythonlibs/ , z dług wdzięczności wobec Christopha Gohlkego z Laboratorium Dynamiki Fluorescencji, UC Irvine.

Uwaga, w obu przypadkach istnieje wiele problemów związanych z licencjami i tak dalej, o których należy pamiętać, ale strona z informacjami wyjaśnia je. Ponownie, wyobrażam sobie, że rozważałeś to, ale jeśli spełniasz wymagania licencyjne (co w Linuksie jest bardzo łatwe do zrobienia), przyspieszyłoby to znacznie część numpy w porównaniu z użyciem prostej automatycznej kompilacji, nawet bez FFTW. Będę zainteresowany śledzeniem tego wątku i zobaczeniem, co myślą inni. Niezależnie od tego, doskonały rygor i doskonałe pytanie. Dzięki za wysłanie.