Biblioteki matematyczne dla OpenCL?

Szukam informacji od każdego, kto próbował użyć OpenCL w swoim kodzie naukowym. Czy ktoś próbował (ostatnio) ViennaCL ? Jeśli tak, to jak to się ma do guzka ?

Co z OCLTools ? Czy to spełnia obietnicę? Jeśli tak, to czy byłby możliwy sposób na rozpoczęcie pisania jądra matematyki w OpenCL?

Przede wszystkim chciałbym podziękować Aronowi Ahmadii za wskazanie mi tego wątku.

Jeśli chodzi o OpenCL w kodzie naukowym: OpenCL ma być niskopoziomowym interfejsem API, dlatego tak ważne jest zawinięcie tej funkcji w celu osiągnięcia rozsądnej wydajności. Co więcej, gdy tylko zaangażowanych jest kilka jąder obliczeniowych, kod może stać się BARDZO brudny, jeśli jądro i uchwyty pamięci OpenCL muszą zostać mocno przekazane w obrębie aplikacji. Nie znam OCLTools, więc nie mogę powiedzieć, czy są przydatne w tym zakresie.

Jeśli chodzi o ViennaCL: Jestem szefem ViennaCL, więc ostatnio pracowałem z biblioteką. :-) Poniżej zajmę się prośbą o porównanie z cuspem w nieco większym zakresie, mianowicie ViennaCL w porównaniu z bibliotekami matematycznymi opartymi na CUDA cusp i MAGMA . Pod uwagę brany jest tylko obecny stan, mimo że postępuje wiele (przynajmniej po naszej stronie).

Funkcjonalność . MAGMA zapewnia funkcjonalność BLAS dla gęstych matryc za pośrednictwem zwykłych interfejsów funkcyjnych. Większość tej funkcjonalności jest również dostarczana z ViennaCL 1.2.0 przy użyciu przeciążeń operatora i innego cukru syntaktycznego.

Te same trzy iteracyjne solwery (CG, BiCGStab, GMRES) są dostarczane z cusp i ViennaCL. Zestaw kondycjonerów różni się znacząco: Cusp zapewnia diagonalną, SA-AMG i różne kondycjonery Bridson. ViennaCL oferuje niekompletne faktoryzacje LU, diagonalne środki kondycjonujące, a ostatnio różne smaki AMG i rzadkie warunki wstępne odwrócone. O ile mi wiadomo, wszystkie wstępne warunki wstępne działają całkowicie na GPU, podczas gdy ViennaCL polega szczególnie na fazie konfiguracji obliczeń opartych na procesorze. Obecnie liczba rzadkich formatów macierzy jest większa w Cusp: COO, CSR, DIA, ELL, HYB, natomiast ViennaCL 1.2.0 zapewnia COO i CSR.

Istnieje szereg dodatkowych funkcji dostarczanych z ViennaCL, które nie są ani częścią MAGMA, ani guzem: Strukturalne typy macierzy (Circulant, Hankel itp.), Szybka transformacja Fouriera, algorytmy zmiany kolejności (np. Cuthill-McKee) i opakowania dla algebry liniowej typy z innych bibliotek.

Wydajność. Większy zestaw funkcji i wsparcia sprzętowego w ViennaCL zazwyczaj kosztuje mniej wydajności w porównaniu do implementacji opartych na CUDA. Wynika to również częściowo z faktu, że CUDA jest dostosowana do architektury produktów NVIDIA, podczas gdy OpenCL stanowi w pewnym sensie rozsądny kompromis między różnymi architekturami wielordzeniowymi.

Ogólnie rzecz biorąc, ViennaCL jest obecnie wolniejszy niż MAGMA, szczególnie na poziomie BLAS 3. Powodem jest inne ukierunkowanie ViennaCL (rzadka zamiast gęstej algebry liniowej), a zatem wyższy stopień optymalizacji w MAGMA. Szczególnie operacje BLAS poziomu 3 są obecnie znacznie szybsze w MAGMA.

Podobnie, guzek zapewnia ogólnie nieco lepszą ogólną wydajność. Ponieważ jednak rzadkie operacje macierzy są zwykle ograniczone pasmem pamięci, różnice są znacznie mniejsze i często pomijalne w porównaniu do konfiguracji danych i tym podobnych. Wybór warunku wstępnego i jego parametrów zwykle ma większy wpływ na ogólny czas wykonania niż jakiekolwiek różnice wydajności w rzadkich multiplikacjach macierz-wektor.

Przenośność . Jeśli chodzi o przenośność sprzętu, ViennaCL może korzystać z procesorów i procesorów graficznych wszystkich głównych dostawców dzięki OpenCL. Natomiast Cusp i MAGMA polegają na odpowiednim procesorze graficznym NVIDIA.

ViennaCL jest tylko nagłówkiem, można go skompilować na wielu kompilatorach C ++ i musi być połączony z biblioteką OpenCL tylko wtedy, gdy wymagana jest obsługa GPU. Zasadniczo ogólne algorytmy w ViennaCL mogą być również używane bez żadnego powiązania z OpenCL, podczas gdy cusp i MAGMA wymagają kompilatora NVIDIA do kompilacji i biblioteki CUDA w systemie docelowym do wykonania. MAGMA wymaga także biblioteki BLAS, która czasem może być trudna do znalezienia lub zainstalowania w nowym systemie.

API . MAGMA zapewnia interfejsy funkcyjne BLAS dla funkcji BLAS. Interfejs Cusp cusp również korzysta z niektórych funkcji z BLAS, ale nie przeciąża operatora. Ponieważ większość interfejsów w ViennaCL jest celowo podobna do Boost.uBLAS i zawiera cukier syntaktyczny, taki jak przeciążenie operatora, ViennaCL jest również przeznaczony do użycia jak Boost.uBLAS. Dlatego oprócz wywoływania predefiniowanego zestawu operacji i algorytmów, naszym celem jest możliwie jak najprostsze przejście od wykonania opartego wyłącznie na procesorze do kodu GPU, nawet jeśli mają być stosowane niestandardowe algorytmy. W przypadku, gdy wymagane jest dedykowane jądro OpenCL, istnieje również struktura integracji własnych jąder OpenCL w ViennaCL. Dlatego ViennaCL ma na celu o wiele więcejwysoka wydajność w tym sensie, że czas wymagany na wdrożenie nowych algorytmów na GPU jest zminimalizowany . Oszczędności te mogą znacznie przewyższyć wszelkie ograniczenia wydajności (jeśli występują) w porównaniu do cusp i MAGMA. (W wątku dotyczącym testowania jednostkowego wspomniano również, że czas opracowywania kodu jest cennym zasobem w nauce).

Z pewnością istnieje wiele problemów ideologicznych (np. CUDA vs. OpenCL, interfejs BLAS vs. przeciążenie operatora) podczas mojego porównania, ale ich dyskusja wykracza poza zakres pytania początkowego.

Z OpenCL można jednak korzystać, ponieważ brakuje infrastruktury, np. Ważne dojrzałe standardowe biblioteki matematyczne z dostrojonymi de facto standardowymi liniowymi komponentami algebry i do pewnego stopnia dobrymi narzędziami do profilowania, chociaż ten drugi problem znacznie się poprawił w przypadku układów GPU. Jest on dostępny w CUDA od dziś i może przyczynić się do części sukcesu Nvidii w tym modelu programowania. Wydaje się jednak, że OpenCL nadrabia zaległości (powoli).

Dzisiaj, jako punkt wyjścia do programowania GPU, CUDA jest w porządku, a jeśli jest to potrzebne, nic nie stoi na przeszkodzie, aby użyć OpenCL jako alternatywy, np. Aby uczynić kod bardziej przenośnym. Zasadniczo ten sam kod jądra może być używany zarówno w CUDA, jak i OpenCL, więc przejście z CUDA do OpenCL nie powinno stanowić większego problemu. Potwierdzają to własne doświadczenia testujące to. Z punktu widzenia wydajności można zastosować te same techniki optymalizacji, aw przypadku trywialnych współbieżnych kompilatorów kodu powinno to zrobić dobrze (np. Rozwijanie pętli itp.).