NVIDIA vs AMD: wydajność GPGPU

Nie mam żadnych silnych uczuć na temat CUDA vs. OpenCL; przypuszczalnie OpenCL jest długoterminową przyszłością, tylko przez dint bycia otwartym standardem.

Ale obecne karty NVIDIA vs ATI dla GPGPU (Nie wydajność grafiki, ale GPGPU), o których mam mocne zdanie. Aby do tego doprowadzić, zwrócę uwagę, że na aktualnej liście Top 500 dużych klastrów , NVIDIA prowadzi systemy AMD 4 do 1, a na gpgpu.org , Wyniki wyszukiwania (referaty, linki do zasobów internetowych itp) dla NVIDIA wyniki dla AMD 6: 1.

Ogromną częścią tej różnicy jest ilość dostępnych informacji online. Sprawdź NVIDIA CUDA Zone kontra GPGPU Developer Central firmy AMD . Ilość rzeczy tam dla deweloperów rozpoczynających się nawet nie zbliży się do porównania. Na stronie NVIDIAs znajdziesz tony dokumentów - i kodu-od osób, które prawdopodobnie pracują nad problemami takimi jak Twój. Znajdziesz mnóstwo klas internetowych, od Nvidii i gdzie indziej i bardzo przydatne dokumenty, takie jak przewodnik najlepszych praktyk programistów itp. Dostępność darmowych narzędzi devel-profiler, cuda-gdb, itp. - w przeważającej mierze przechyla NVIDIAs sposób.

(redaktor: informacje w tym akapicie nie są już dokładne.), A pewną różnicą jest również sprzęt. Karty AMDs mają lepsze specyfikacje pod względem szczytowych flopów, ale aby uzyskać znaczną część tego, musisz nie tylko rozbić swój problem na wiele całkowicie niezależne procesory strumieniowe, każdy element roboczy również musi być wektoryzowany. Biorąc pod uwagę, że kod GPGPUing ones jest wystarczająco trudny, że dodatkowa złożoność architektoniczna wystarczy, aby wykonać lub złamać niektóre projekty.

A rezultatem tego wszystkiego jest to, że społeczność użytkowników NVIDII wciąż się rozrasta. Z trzech lub czterech grup, które znam, myśląc o budowaniu klastrów GPU, żadna z nich nie bierze poważnie pod uwagę kart AMD. A to oznacza jeszcze więcej grup piszących prace, wnoszących kod itp. na po stronie NVIDII.

Nie jestem NVIDIA shill; szkoda, że tak nie było i że były dwa (lub więcej!) równie atrakcyjne platformy GPGPU. Konkurencja jest dobra. Być może AMD wkrótce podniesie swoją grę - a nadchodzące produkty fusion wyglądają bardzo atrakcyjnie. Ale udzielając komuś porad, które karty kupić dzisiaj i gdzie spędzić czas wkładając wysiłek w tej chwili, nie mogę z czystym sumieniem powiedzieć, że oba Środowiska programistyczne są jednakowo dobrze.

Edytowane, aby dodać: myślę, że powyższe jest trochę eliptyczne pod względem odpowiedzi na pierwotne pytanie, Więc pozwól, że to trochę bardziej wyraźne. Wydajność, jaką można uzyskać z danego sprzętu, jest w idealnym świecie z nieskończonym dostępnym czasem, zależna tylko od podstawowego sprzętu i możliwości języka programowania; ale w rzeczywistości, ilość wydajności, którą można uzyskać w ustalonej ilości zainwestowanego czasu, jest również silnie zależna od narzędzi devel, istniejące bazy kodu społeczności (np. publicznie dostępne biblioteki itp.). Wszystkie te rozważania mocno wskazują na Nvidię.

(redaktor: informacje w tym akapicie nie są już dokładne.) Jeśli chodzi o sprzęt, wymóg wektoryzacji w jednostkach SIMD w kartach AMD również sprawia, że osiągnięcie wydajności papieru jest jeszcze trudniejsze niż w przypadku sprzętu NVIDIA.

Główna różnica między architekturami AMD i Nvidii polega na tym, że AMD jest zoptymalizowana pod kątem problemów, w których zachowanie algorytmu może być określone w czasie kompilacji, podczas gdy NVIDIA jest zoptymalizowana pod kątem problemów, w których zachowanie algorytmu może być określone tylko w czasie wykonywania.

AMD ma stosunkowo prostą architekturę, która pozwala im wydać więcej tranzystorów na ALU. tak długo, jak problem może być w pełni zdefiniowany w czasie kompilacji i być z powodzeniem odwzorowany na architekturę w nieco statyczny lub liniowy sposób istnieje duża szansa, że AMD będzie w stanie uruchomić algorytm szybciej niż NVIDIA.

Z drugiej strony, kompilator NVIDII robi mniej analiz w czasie kompilacji. Zamiast tego NVIDIA ma bardziej zaawansowaną architekturę, w której wydała więcej tranzystorów na logikę, która jest w stanie obsłużyć dynamiczne zachowanie algorytmu, które pojawia się tylko w czasie wykonywania.

Uważam, że większość superkomputerów korzystających z GPU korzysta z Nvidii, że typ problem, na którym naukowcy są zainteresowani uruchamianiem obliczeń, ogólnie lepiej odwzorowuje architekturę NVIDII niż AMD.

Zrobiłem kilka iteracyjnych kodowań w OpenCL. A wyniki jego uruchomienia w Nvidii i ATI są prawie takie same. Blisko tej samej prędkości w kartach o tej samej wartości ( $ ).

W obu przypadkach prędkość była ~10x - 30x w porównaniu do procesora.

Nie testowałem CUDA, ale wątpię, żeby to magicznie rozwiązało moje problemy z losową pamięcią. W dzisiejszych czasach CUDA i OpenCL są mniej więcej takie same i widzę więcej przyszłości na OpenCL niż na CUDA. Głównym powodem jest to, że Intel wprowadza sterowniki z OpenCL dla ich procesorów. Będzie to ogromny postęp w przyszłości (uruchamianie 16, 32 lub 64 wątków OpenCL W CPU jest naprawdę szybkie i naprawdę łatwe do portu na GPU).

Po spędzeniu trochę czasu z OpenCL dla kart GCN po kilku latach CUDA dla Fermi i Kepler, nadal wolę CUDA jako język programowania i wybrałbym sprzęt AMD z CUDA, gdybym miał opcję.

Dla AMD:

• Nawet w przypadku Maxwella, NVidia nadal ma dłuższe opóźnienia poleceń, a złożone algorytmy prawdopodobnie będą o 10 szybsze NA AMD (zakładając te same teoretyczne Tflops) po łatwych optymalizacjach dla obu. Luka była do 60% Dla Kepler VS GCN. W tym sensie trudniej jest zoptymalizować złożone jądra dla Nvidii.

• Tanie karty.

• OpenCL jest otwartym standardem z innymi dostępnymi dostawcami.

Dla Nvidii:

• Posiada linię sprzętu Tesla, która nadaje się do niezawodnych wysokich obciążeń serwerów.

• Nowy Maxwell jest dużo bardziej energooszczędny.

• Kompilator i narzędzia są znacznie bardziej zaawansowane. AMD nadal nie może dostać aby zaimplementować parametr maxregcout, możesz łatwo kontrolować zajętość na różnych urządzeniach, a ich kompilator ma wiele losowych pomysłów na optymalny kod, który zmienia się wraz z każdą wersją, więc może być konieczne ponowne odwiedzanie starego kodu co pół roku, ponieważ nagle stał się 40% wolniejszy.

W tym momencie, jeśli GPGPU jest twoim celem, CUDA jest jedynym wyborem, ponieważ opencL z AMD nie jest gotowy do farmy serwerów i znacznie trudniej jest napisać wydajny kod dla AMD ze względu na fakt że kompilator zawsze wydaje się być "w wersji beta".

Jestem nowy w GPGPU, ale mam pewne doświadczenie w informatyce naukowej (doktorat z fizyki). Składam zespół badawczy i chcę przejść do korzystania z GPGPU dla moich obliczeń. Musiałem wybrać pomiędzy dostępnymi platformami. Zdecydowałem się na Nvidię, z kilku powodów: chociaż ATI może być szybsze na papierze, Nvidia ma bardziej dojrzałą platformę i więcej dokumentacji, więc będzie można zbliżyć się do maksymalnej wydajności na tej platformie.

Nvidia ma również akademicką program wsparcia badań, można ubiegać się o wsparcie, Właśnie otrzymałem kartę TESLA 2075, z której jestem bardzo zadowolony. Nie wiem czy ATI czy Intel wspiera badania w ten sposób.

To, co słyszałem o OpenCL jest to, że stara się być wszystkim na raz, to prawda, że Twój kod OpenCL będzie bardziej przenośny, ale jest również prawdopodobne, że nie wykorzysta pełnych możliwości obu platform. Wolałbym nauczyć się trochę więcej i pisać programy, które lepiej wykorzystują zasoby. Z TESLA K10 że właśnie wyszedł w tym roku Nvidia jest w zakresie 4.5 TeraFlops więc nie jest jasne, że Nvidia jest w tyle ... jednak Mikrofony Intela mogą okazać się prawdziwym konkurentem, zwłaszcza jeśli uda im się przenieść jednostkę GPGPU na płytę główną. Ale na razie wybrałem Nvidię.

Moje doświadczenie w ocenie wydajności zmiennoprzecinkowej OpenCL ma tendencję do faworyzowania kart NVIDIA. Pracowałem z kilkoma zmiennoprzecinkowymi benchmarkami na kartach NVIDIA, od 8600M GT po GTX 460. Karty NVIDIA konsekwentnie osiągają około połowę teoretycznego szczytu single-precisino na tych benchmarkach.
Karty ATI, z którymi pracowałem rzadko osiągają lepsze wyniki niż jedna trzecia piku single-precision. Zauważ, że moje doświadczenie z ATI jest wypaczone; udało mi się pracować tylko z jednym Karta serii 5000. Moje doświadczenie dotyczy głównie kart z serii HD 4000, które nigdy nie były dobrze obsługiwane. Obsługa kart z serii HD 5000 jest znacznie lepsza.

Chciałbym dodać do debaty. Dla nas w branży oprogramowania, możemy skompromitować surową wydajność z pojedynczą precyzją do produktywności, ale nawet to nie muszę iść na kompromis, ponieważ, jak już wspomniano, nie można osiągnąć tak dużej wydajności na sprzęcie ATI za pomocą OpenCL, jak można osiągnąć, jeśli piszesz w CUDA na sprzęcie NVIDIA.

I tak, z zapowiedzią kompilatora x86 dla CUDA, nie będzie żadnego dobrego powodu, aby poświęcać więcej czasu i zasobów na pisanie w OpenCL:)

P. S: mój argument może być stronniczy, ponieważ wykonujemy prawie wszystkie nasze prace GPGPU na CUDA. Mamy przetwarzania obrazu / Computer Vision library CUVI (CUDA dla wizji i obrazowania), który przyspiesza niektóre podstawowe funkcje IP / CV na CUDA.

Cuda jest z pewnością popularny niż OpenCL dzisiaj, ponieważ został wydany 3 lub 4 lata przed OpenCL. Od czasu wydania OpenCL, Nvidia nie wniosła zbyt wiele do języka, ponieważ koncentrują się na CUDA. Nie wydali nawet wersji openCL 1.2 Dla żadnego sterownika.

Jeśli chodzi o obliczenia heterogeniczne, a także urządzenia ręczne, o których mowa, OpenCl z pewnością zyska większą popularność w niedalekiej przyszłości. Obecnie największym współtwórcą OpenCL jest AMD, jest on widoczny na ich miejscu.

Z mojego doświadczenia:

• Jeśli chcesz uzyskać najlepszą wydajność absolutną, musisz sprawdzić, kto jest na najnowszej iteracji sprzętowej i użyć ich stosu (w tym najnowszych wydań / wersji beta).

• Jeśli chcesz uzyskać najlepszą wydajność za pieniądze, będziesz dążyć do kart graczy, a nie "profesjonalnych" kart, a elastyczność targetowania różnych platform sprzyja opencl.

• Jeśli zaczynasz, w szczególności, cuda wydają się być bardziej dopracowane i mieć więcej narzędzi i bibliotek.

Wreszcie, moje osobiste podejście, po przerażającym "wsparciu" ze strony Nvidii( mamy martwą Teslę i nie zmieniło się to od miesięcy, gdy klient czekał): elastyczność, aby przejść statek z opencl jest warta ryzyka nieco niższej wydajności, gdy nvidia jest do przodu w cyklu wydania.