Przyszłość OpenCL?

Paradygmat programowania OpenCL zapowiada się jako darmowy, otwarty standard dla heterogenicznych obliczeń. Czy powinniśmy poświęcać czas na tworzenie oprogramowania opartego na OpenCL? Za I przeciw?

Pytanie jest zbyt ogólne i niejasne, aby można było na nie odpowiedzieć. Widzę jednak jeden znaczący punkt w stosunku do OpenCL, z punktu widzenia obliczeń naukowych, który rzadko jest podkreślany. Do tej pory nie starano się tworzyć bibliotek infrastruktury Open Source dla OpenCL, podczas gdy CUDA ma kilka doskonałych opcji:

• KUBLAS , MANKIET , KUSZARKA
• Pchnięcie , Kolec , OpenCurrent
• Wsparcie PETSc

Wierzę, że to naprawdę zaszkodzi OpenCL, ponieważ głównym czynnikiem ułatwiającym adopcję są otwarte biblioteki wysokiej jakości.

OpenCL vs co?

Jeśli pytanie brzmi: OpenCL vs. CUDA, widzę, że to pytanie wymaga dużo pracy i wydaje mi się to szalone. To nie ma znaczenia Szczery. Jądra - tam, gdzie musi iść całe trudne myślenie - są praktycznie identyczne między dwoma językami; możesz napisać makra dla swojego ulubionego edytora, aby wykonać 99% pracy, aby odbić się między OpenCL i CUDA. Tak musi być; kontrolują one na niskim poziomie ostatecznie całkiem podobny rodzaj sprzętu. Gdy nauczysz się pisać ważne jądra w {OpenCL, CUDA}, przeniesienie ich do {CUDA, OpenCL} jest banalne.

Kod hosta, który musisz napisać, jest również podobny, ale CUDA upraszcza proste przypadki. Dlatego uczymy CUDA w naszym centrum; możesz od razu przejść do pisania kodu jądra, podczas gdy musielibyśmy spędzić 1-2 godziny naszego całodziennego kursu, wyjaśniając tylko kwestie związane z uruchamianiem jądra dla OpenCL.

Ale nawet tam różnica nie jest tak ważna; kiedy zaczniesz robić bardziej skomplikowane rzeczy (jądra asynchroniczne na wielu systemach gpus), oba są równie skomplikowane i znowu możesz praktycznie wykonać tłumaczenie wiersz po wierszu z jednego na drugi.

Jeśli jest to OpenCL w porównaniu z podejściem opartym na dyrektywach - OpenACC lub HMPP lub coś w tym rodzaju - to prawdopodobnie (mam nadzieję?) Będą to dobre sposoby programowania tego rodzaju architektur w przyszłości, w których można uzyskać 90% wydajności dla 10% pracy. Ale wybór, który „wygra”, dopiero się okaże i nie zaleciłbym spędzania dużo czasu z nimi pracując.

Powiedziałbym więc, że pomiędzy CUDA a OpenCL wybierz język, który jest dla Ciebie wygodny i używaj go, i nie martw się zbytnio o to. Cenna część - zastanawianie się, jak rozłożyć problem na masowo równoległy kod SIMD dla małych rdzeni z bardzo małą pamięcią - będzie dość łatwa do przenoszenia między modelami programowania.

Jeśli używasz sprzętu NVIDIA - i prawdopodobnie tak jest - wtedy zazwyczaj polecam CUDA - punkt Matt'a Knepleya na temat bibliotek jest martwy. Jeśli nie, to OpenCL.

To, czy powinieneś poświęcić swój czas na tworzenie oprogramowania opartego na OpenCL, to pytanie, na które tylko Ty możesz odpowiedzieć. Jeśli wygląda na to, że może rozwiązać problemy, z którymi się teraz borykasz, a żadne inne otwarte rozwiązanie tego nie robi, najlepszym rozwiązaniem jest prawdopodobnie podjęcie ryzyka przy realizacji małego projektu.

Jeśli to pójdzie dobrze, możesz wypróbować to przy większych projektach i tak dalej, aż albo zbudujesz wystarczającą pewność siebie, by się w nim ujednolicić, albo odrzucisz je na rzecz innego rozwiązania (które może być Twoim własnym, innym rozwiązaniem otwartym, a nawet inne autorskie rozwiązanie).

Cudowną rzeczą w ruchu open source jest to, że ponieważ masz źródło , masz wszystko, czego potrzebujesz, aby rozwidlić projekt, jeśli to konieczne. Nawet jeśli sama społeczność nie zapewnia potrzebnych Ci udogodnień, nic nie stoi na przeszkodzie, abyś sam je wdrożył. Ponadto, jeśli chciałeś tych udogodnień, istnieje wyraźna możliwość, że inni użytkownicy mogą ich chcieć, więc docenilibyśmy to, gdybyś wniósł te zmiany z powrotem do głównego projektu.

Nie tylko to, ale jeśli poprawisz to z swojej perspektywy, może to poprawić dla innych, zachęcić ich do przedstawienia własnych ulepszeń i ostatecznie ulepszyć oprogramowanie dla wszystkich.

Wreszcie tak, jest to raczej ogólna odpowiedź na raczej ogólne pytanie. Aby uzyskać pełniejszą odpowiedź, musimy wiedzieć, jakie są Twoje obawy dotyczące OpenCL. Czy to dojrzałość? Społeczność? Łatwość użycia? Czas potrzebny na naukę? Czas się rozwijać? Zmieniasz swoje procedury? Kiedy pytasz o wady i zalety, z jakimi innymi produktami próbujesz porównać OpenCL ? Jakie badania już przeprowadziłeś? Jakie funkcje są potrzebne do obsługi heterogenicznego środowiska komputerowego?

Jednym wielkim PRO jest liczba dostawców stojących za OpenCL. Mam trochę niepotwierdzonych doświadczeń na ten temat, ponieważ spotkałem grupę badawczą, która poświęciła dużo czasu i wysiłku na opracowanie dość skomplikowanego kodu CUDA dla systemu napędzanego NVIDIA. Rok później po opracowaniu kodu grupa badawcza uzyskała dostęp do większego i szybszego systemu opartego na AMD, ale nie mogła go użyć, ponieważ nie miała zasobów (ludzkich) do przeniesienia kodu.

Nawet jeśli podstawowy zestaw funkcji CUDA i OpenCL jest prawie identyczny (jak dobrze zauważył @JonathanDursi), jeśli pierwotny programista nie jest tym, któremu powierzono zadanie konwersji kodu, cały projekt przenoszenia może być dość czasochłonny.

Istnieją jednak pewne oficjalne niezgodności między CUDA i OpenCL. Najbardziej niezwykłe CUDA obsługuje szablony c ++, podczas gdy OpenCL jeszcze ich oficjalnie nie obsługuje. Jednak AMD dokłada starań, aby opracować rozszerzenie do OpenCL z obsługą szablonów i innych funkcji C ++, więcej informacji w tym poście od AMD Dev Central . Mam nadzieję, że przyszła wersja OpenCL może dodać tę pracę.

W tym momencie (na początku 2012 r.) Niesamowite biblioteki, do których prowadzi link @MattKnepley, to zamknięte źródła lub szablony, więc nie będą one dostępne dla sprzętu innego niż NVIDIA, przynajmniej w międzyczasie.

Dla kogoś, kto uczy się obliczeń GPU, powiedziałbym, że OpenCL C może być dość trudny, ponieważ istnieje wiele szczegółów, które odwracają uwagę ucznia od podstawowych pomysłów, podczas gdy CUDA jest prostszy i bardziej bezpośredni. Istnieją jednak narzędzia, które znacznie upraszczają naukę i używanie OpenCL, takie jak PyOpenCL (otoki Pythona dla opencl), która przenosi cały cukier pythonowy do OpenCL (zwróć uwagę, że istnieje również PyCUDA). Na przykład, demo PyOpenCL do dodawania dwóch tablic ma nieco mniej niż 25 linii i obejmuje: tworzenie tablic na hoście i urządzeniu, transfery danych, tworzenie kontekstu i kolejki, jądro, jak zbudować i wykonać jądro , uzyskiwanie wyników z GPU i porównywanie ich z numpy (patrz linki poniżej).

PyOpenCL - http://mathema.tician.de/software/pyopencl

PyCUDA - http://mathema.tician.de/software/pycuda

Dla doświadczonych programistów GPU, tutaj zgadzam się z @JonathanDursi, CUDA i OpenCL są zasadniczo takie same i tak naprawdę nie ma różnic burmistrza. Co więcej, ciężka praca nad opracowaniem wydajnego algorytmu dla układów GPU jest w dużej mierze niezależna od języka, a obsługa OpenCL od dostawców i dokumentacji jest teraz znacznie bardziej dojrzała niż powiedzmy 2 lata temu. Jedyną kwestią, która wciąż robi różnicę, jest to, że NVIDIA naprawdę robi świetną robotę, wspierając społeczność CUDA.

OpenCL ma tę dodatkową zaletę, że może działać na procesorach i jest już obsługiwany przez Intel i AMD. Nie musisz więc zmieniać struktury algorytmu, jeśli chcesz skorzystać z dostępnych rdzeni procesora. Nie uważam, że OpenCL jest najlepszym rozwiązaniem dla pojedynczej aplikacji zorientowanej na procesor / procesor, ponieważ jądro zoptymalizowane pod kątem procesora może wyglądać znacznie inaczej niż jądro zoptymalizowane pod kątem GPU. Jednak z mojego doświadczenia wynika, że ​​rozwój CODE korzysta z możliwości działania na procesorze.

Myślę, że OpenCL obecnie cierpi na brak „mistrza”. Na przykład, jeśli odwiedzasz teraz witrynę NVIDIA (16.12.2011), masz kilka ujęć w stylu „efektu Kena Burnsa” na stronie powitalnej skupiającej się na naukowej / przemysłowej stronie obliczeń na GPU i ~ 1 / Czwarta z opcji nawigacji prowadzi do rzeczy, które prawdopodobnie trafią do CUDA. Producenci sprzedający serwery i stacje robocze „GPU” sprzedają rozwiązania NVIDIA.

Konkurencyjne oferty ATI są mieszane z ogólną witryną AMD, trudniejsze do znalezienia i nie tak mocno prezentowane w rozwiązaniach innych firm. Te rozwiązania i możliwość programowania opartego na OpenCL z pewnością istnieją, ale pozostawiło wrażenie - przynajmniej w mojej głowie, ale w umysłach innych osób, z którymi rozmawiałem - że duzi sponsorzy korporacyjni platformy OpenCL już „ wyjdź z pola ". Na przykład osoby korzystające z systemu OS X są prawdopodobnie zbyt zajęte spekulacjami na temat tego, czy stacja robocza Apple będzie istnieć nawet za rok, aby wierzyć w to, że wykorzystują procesory graficzne OpenCL.

Najważniejszym czynnikiem jest to, że CUDA pozostanie obsługiwany tylko przez sprzęt NVIDIA.

Dlatego jeśli chcesz stworzyć solidne i przenośne oprogramowanie, OpenCL jest jedyną opcją. Co najwyżej możesz zbudować wokół niektórych bibliotek opartych na CUDA i mam nadzieję, że zostaną one rozszerzone w stosunku do OpenCL w przyszłości, pociągając za sobą kod.