GPGPU kontra Multicore?

Ciekawe pytanie. Zbadałem ten problem, więc moja odpowiedź opiera się na pewnych referencjach i osobistych doświadczeniach.

Jakie typy problemów są lepiej dopasowane do zwykłego wielordzeniowego i jakie typy są lepiej dopasowane do GPGPU?

Jak wspomniał @ Jared. GPGPU są zbudowane dla bardzo regularnych obciążeń przepustowości, np. grafika, gęsta matryca-mnożenie macierzy, Proste filtry photoshop, itp. Są dobrzy w tolerowaniu długich opóźnień, ponieważ są z natury zaprojektowany, aby tolerować próbkowanie tekstur, ponad 1000 cykli pracy. Rdzenie GPU mają wiele wątków: gdy jeden wątek uruchomi operację z długim opóźnieniem (powiedzmy dostęp do pamięci), wątek ten zostanie uśpiony (a inne wątki będą działać), dopóki operacja z długim opóźnieniem się nie zakończy. Dzięki temu procesory GPU mogą zajmować jednostki wykonawcze znacznie więcej niż tradycyjne rdzenie.

GPU nie radzą sobie z gałęziami, bo GPU lubią wsadzać "wątki" (SIMD, jeśli nie nVidia) do warpów i wysyłać je w dół potoku razem, aby zaoszczędzić na instrukcji pobierania / dekodowania mocy. Jeśli wątki napotkają gałąź, mogą się różnić, np. 2 wątki w osnowie 8-nitkowej mogą wziąć gałąź, podczas gdy pozostałe 6 może jej nie wziąć. Teraz warp musi być podzielony na dwie warpy wielkości 2 i 6. Jeśli twój rdzeń ma 8 pasów SIMD (dlatego oryginalny warp pakował 8 wątków), teraz Twoje dwa nowo utworzone warpy będą działać nieefektywnie. Osnowa 2-nitkowa będzie działać z wydajnością 25%, A osnowa 6-nitkowa będzie działać z wydajnością 75% wydajność. Można sobie wyobrazić, że jeśli GPU nadal napotyka zagnieżdżone gałęzie, jego wydajność staje się bardzo niska. Dlatego GPU nie są dobre w obsłudze gałęzi i dlatego kod z gałęziami nie powinien być uruchamiany na GPU.

GPU są również złe współpracy wątków. Jeśli wątki muszą ze sobą rozmawiać, to GPU nie będzie działać dobrze, ponieważ synchronizacja nie jest dobrze obsługiwana na GPU (ale nVidia jest na nim).

Dlatego najgorszym kodem dla GPU jest kod o mniejszej równoległości lub kod z dużą ilością gałęzi lub synchronizacji.

Jakie są główne różnice w modelu programowania?

GPU nie obsługują przerwań i WYJĄTKÓW. Dla mnie to największa różnica. Poza tym CUDA nie różni się zbytnio od C. możesz napisać program CUDA, w którym wysyłasz kod do GPU i uruchamiasz go tam. Masz dostęp do pamięci w CUDA trochę inaczej, ale znowu to nie jest fundamentalne dla naszej dyskusji.

Jakie są kluczowe elementy sprzętowe różnice, które wymagają jakichkolwiek różnic w modelu programowania?

Już o nich wspomniałem. Największy jest charakter SIMD GPU, który wymaga kodu do pisania w bardzo regularny sposób, bez gałęzi i komunikacji między wątkami. Jest to część tego, dlaczego np. CUDA ogranicza liczbę zagnieżdżonych gałęzi w kodzie.

Który z nich jest zazwyczaj łatwiejszy w użyciu i o ile?

Zależy od tego, co kodujesz i jaki jest twój cel.

Łatwo wektoryzowalny kod: procesor jest łatwiejszy w kodowaniu, ale o niskiej wydajności. GPU jest nieco trudniejsze do zakodowania, ale zapewnia wielki wybuch dla kasy. Dla wszystkich innych procesor jest łatwiejszy i często lepsza wydajność.

Czy jest to praktyczne, w dłuższej perspektywie, zaimplementować biblioteki równoległości wysokiego poziomu dla GPU, takie jak Microsoft 's task parallel library lub D' s std.paralelizm?

Task-paralelizm, z definicji, wymaga komunikacji wątkowej i ma również gałęzie. Idea zadań polega na tym, że różne wątki robią różne rzeczy. GPU są przeznaczone dla wielu wątków, które robią identyczne rzeczy. Nie budowałbym bibliotek paralelizmu zadań dla GPU.

Jeśli procesory graficzne są tak spektakularnie wydajne, dlaczego Procesory nie są zaprojektowane bardziej jak GPU?

Wiele problemów na świecie jest rozgałęzionych i nieregularnych. 1000 przykładów. Algorytmy wyszukiwania wykresów, systemy operacyjne, przeglądarki internetowe itp. Dodam tylko, że nawet grafika staje się bardziej i bardziej rozgałęzione i ogólnego przeznaczenia, jak każda generacja, więc GPU będzie coraz bardziej podobny do procesorów. Nie mówię, że staną się tak samo jak procesory, ale staną się bardziej programowalne. Odpowiedni model znajduje się gdzieś pomiędzy nieefektywnymi procesorami a bardzo wyspecjalizowanymi procesorami graficznymi.