Programowanie współbieżne, Języki programowania, Aplikacje, Gry

CPU vs GPU: GFLOPS

Czytając różne informacje o kartach graficznych możemy się dowiedzieć, że ich wydajność jest wielokrotnie większa od odpowiednich im cenowo procesorów x86. Często można też zobaczyć liczby w postaci nawet ponad 2TFLOPSów dla GPU i maksymalnie 100GFLOPS dla najszybszych CPU. Dzisiaj postaram się opowiedzieć o teoretycznej wydajności różnych układów i tego w jaki sposób można ją obliczyć. Natomiast w kolejnych postach opisze różnice w architekturze CPU i GPU AMD i NVidii i to jak wpływają one na poziom wykorzystania teoretycznej wydajności.

Zanim jednak przejdę do sedna sprawy muszę napisać pewne uaktualnienie do mojego poprzedniego posta o podstawach GPU. Po jego publikacji AMD wydało w końcu sterowniki (Catalyst 9.12 Hotfix) z obsługą DirectCompute 4.1 dla Radeonów 48xx i 47xx. Niestety część osób będzie zawiedziona. Nadal brakuje obsługi DirectCompute w Radeonach 46xx i słabszych, które również były często kupowane. Podobnie lista rozszerzeń OpenCL dla mojego Radeona 4850 jest ciągle pusta. Pisząc o podstawach GPU pominąłem także jedną ale do niektórych zastosowań ważną rzecz. Radeony 47xx, 48xx, 58xx posiadają obsługę obliczeń na liczbach podwójnej precyzji. NVidia z kolei podwójną precyzje posiada tylko w układach opartych na GT200 i jej implementacja jest dość wolna. Dokładniejsze liczby podam w dalszej części postu.

Na początku postu wspomniałem o FLOPSach i myślę że warto napisać najpierw co to jest. Dość dobrą definicje można przeczytać na wikipedii: http://pl.wikipedia.org/wiki/FLOPS. Jednak na powyższej stronie nie ma wyraźnie zaznaczonej jednej sprawy. Wydajność we FLOPS jednej i tej samej maszyny może dotyczyć różnych rzeczy: (i mieć w zależności od tego inną wartość)

  1. Teoretycznej wydajności wszystkich jednostek obliczeniowych opierając się przede wszystkim na operacjach dodawania i mnożenia bez takich operacji jak np. shift.
  2. Wydajności, która została uzyskana w określonym benchmarku. Taka wydajność będzie przeważnie niższa od wartości z pkt1 w związku z np czekaniem na pobranie danych z pamięci, niemożnością wykorzystania specyficznych jednostek przystosowanych tylko do pewnych operacji czy niemożliwością równoległego wykorzystania kilku jednostek z powodu zależnych od siebie operacji. Podobnie jak w poprzednim przypadku liczone są operacje dodawania i mnożenia wykonywane przez benchmark.

Opisywanie teoretycznej wydajności zaczne od dzisiejszych najmocniejszych jednostek CPU. Weźmy dla przykładu czterordzeniowy Core i7. Każdy z rdzeni posiada jedną jednostkę odpowiedzialną za dodawanie na 128bitowych danych i jedną jednostke do mnożenia na 128bitowych danych co oznacza mniej więcej maksymalnie:

  • 2 operacje x87 na rozszerzonych 80bitowych liczbach zmiennoprzecinkowych w jednym cyklu zegara
  • 4 operacje SSE na 64bitowych liczbach zmiennoprzecinkowych (podwójna precyzja) w jednym cyklu zegara
  • 8 operacji SSE na 32bitowych liczbach zmiennoprzecinkowych (pojedyncza precyzja) w jednym cyklu zegara

Co dla czterordzeniowego Core i7 o taktowaniu 3GHz oznacza wydajność odpowiednio 24GFlops, 48GFlops, 96GFlops dla danego typu operacji czyli całkiem sporo.

Dalej mamy np układ GeForce GTX 280. Do dyspozycji mamy tutaj 30 multiprocesorów, z których każdy posiada 8 jednostek SP (Shader Processor) o wydajności 2 operacje pojedynczej precyzji (jedna operacja mad czyli jedna operacja mnożenia i jedna dodawania (a*b+c)) na jeden cykl i dodatkowo 2 jednostki SFU (Special Function Unit), każda o wydajności 1 operacja specjalna (sin, log, sqrt) lub 4 operacje mnożenia na cykl (dzięki tzw. ‚dual issue’). Razem daje to 30*(8*2 + 2*4) = 720 operacji na jeden cykl dla całego GPU. Mnożąc to przez częstotliwość „szaderów” czyli 1296MHz otrzymujemy 933GFLOPS!

Niestety wydajność tego samego układu w podwójnej precyzji jest znacznie mniejsza. Każdy multiprocesor potrafi wykonać tylko jedną operacje MAD (liczoną jako dwie operacje).  Jednostki SFU nie operują w ogóle na 64bitowych liczbach zmiennoprzecinkowych. Co przekłada się na „tylko” 30*2 = 60 operacji na jeden cykl. Przy częstotliwości 1296MHz daje to ok 78GFlops.

Konkurencyjny Radeon 4870 wydany w podobnym czasie co GTX280 posiada 160 SP pogrupowanych po 16SP w jednym SIMD Engine. Każdy shader składa się z 5 jednostek SPu potrafiących wykonać jedną operacje mad na cykl (także liczone jako 2 operacje na cykl). Dodatkowo jedna z tych 5 jednostek potrafi wykonać jedną instrukcję specjalną na cykl (zamiast instrukcji mad). Razem daje to 10 * 16 * 5 * 2 = 1600 operacji na cykl czyli 1.2TFlops przy częstotliwości 750MHz. Jak widać teoretyczna wydajność Radeona 4870 jest większa niż GeForca GTX280.

W przypadku podwójnej precyzji przewaga Radeona znacznie się zwiększa, gdyż każdy SP potrafi wykonać jedną instrukcje MAD na cykl co daje 10*16*2=320 operacji na cykl co przekłada się na 240GFlops. Ponad 3x więcej niż GTX280! O ile w przypadku pojedynczej precyzji GeForce „nadrabia architekturą” i w wielu przypadkach jest szybszy od Radeona to w double precision trzeba uznać wyższość Radeona. Od razu jednak przypomnę że, aby wydobyć pełnię mocy Radeona trzeba wykorzystać niezbyt wygodny CAL.

Najnowszy Radeon 5870 z punktu widzenia dzisiejszego tematu postu jest podwojonym Radeonem 4870 (zamiast 10 SIMD Engine mamy ich 20) co oznacza 3200 operacji na cykl dla pojedynczej precyzji i 640 operacji dla podwójnej precyzji. Przy zwiększonym taktowaniu rdzenia do 850MHz otrzymujemy 2.72TFlops dla pojedynczej precyzji i 544GFlops dla podwójnej.

Niestety ciągle nie wiadomo jakie parametry będzie miał zapowiadany układ GF100 od NVidii. Brakuje informacji o częstotliwości rdzeni i dokładniejszych informacji o jednostkach SFU. Można jednak spodziewać się wyraźnie wyższej wydajności od Radeona 5870 w podwójnej precyzji i wyraźnie niższej wydajności w pojedynczej precyzji.

Na koniec warto przypomnieć że teoretyczna maksymalna wydajność to nie wszystko. Układy CPU mimo iż teoretycznie wielokrotnie wolniejsze od GPU w wielu zastosowaniach są niezastępowalne. Podobnie Radeon 4870 teoretycznie szybszy od GeForca GTX 280 przegrywa z nim w prawie każdej grze. W kolejnych postach postaram się opisać różnice w architekturze, które decydują o wydajności w realnych zastosowaniach.

4 komentarze to “CPU vs GPU: GFLOPS”

  1. Bardzo interesujący blog. Super artykuły. Ja mam kilka pytań.

    Czy te nowe rozwiązania są gwoździem do trumny dla systemu Windows Xp który ja wiadomo nie będzie miał DirectX 11. Jak to jest z tym dx11 i DirectCompute nie spotkałem aplikacji korzystając z tego rozwiązania (sam win7 też z niego nie korzysta). Czy przypadkiem duża konkurencja pomiędzy ati i nvidia nie sprawa że ważniejsze są ich autorskie rozwiązania.

    Czy można powiedzieć ze DirectX ma DirectCompute a OpenGL ma OpenCL?

    Chciałbym przeczytać Pana opinie jak to wszystko wpłynie na systemy operacyjne (czy linux zyska, windows xp straci ird..)

  2. Witam.

    „Czy można powiedzieć ze DirectX ma DirectCompute a OpenGL ma OpenCL?”
    Jest w tym trochę prawdy ale tylko trochę. DirectCompute jest integralną częścią DirectX 11. OpenCL jest niezależny od OpenGL. Tzn można posiadać najnowsze biblioteki OpenGL i jednocześnie nie mieć OpenCL. Podobnie można mieć możliwość uruchamiania aplikacji OpenCL bez posiadania OpenGL czy nawet jakiejkolwiek karty graficznej w systemie. Choć rzeczywiście OpenCL posiada funkcje do współpracy z OpenGL to są one opcjonalne. Co jest zresztą zrozumiałe skoro OpenCL został stworzony z myślą o wykorzystaniu nie tylko GPU a także CPU czy innych APU (Accelerated Processing Unit). DirectCompute został stworzony z troszkę innymi założeniami. Ma przede wszystkim udostępnić moc GPU jak najlepiej integrując się z DirectX.

    „Czy te nowe rozwiązania są gwoździem do trumny dla systemu Windows Xp który ja wiadomo nie będzie miał DirectX 11”.
    Na pewno jest to jakiś powód aby przejść z Windows XP na Windows 7 lub Vista. Natomiast nie nazwałbym tego „gwoździem do trumny”. Głównie z trzech powodów:
    1. Windows 7 jest według mnie bardzo udanym systemem, ma bogatszą funkcjonalność i prawie na każdym obecnie sprzedawanym komputerze stacjonarnym czy nawet laptopie będzie chodził lepiej, wydajniej niż Windows XP. Co więcej doszliśmy już do granicy adresowania w 32bit (4GB) i 64bitowy Windows 7 jest już dla wielu ludzi naturalnym wyborem. To jak dla mnie są główne powody dlaczego ludzie będą wybierać Windows 7.
    2. DirectCompute będzie używany głównie w aplikacjach, które do tej pory korzystały już z innych elementów DirectX czyli np w grach. Należy jednak pamiętać że Windows XP jest ciągle najpopularniejszym systemem i nikt na razie nie pozwoli sobie na wydanie gry „Windows Vista & Windows 7 only”. Przez najbliższy rok albo dwa będziemy mieć premiery gier wspierających zarówno DirectX 9c jak i DirectX11. Oczywiście pod Windows XP i DirectX 9c nie będziemy mieć wielu efektów, ale z drugiej strony do DirectX11 będziemy potrzebować też dużo lepszego sprzętu. A skoro musimy zaopatrzyć się w nowszy sprzęt to i naturalnym stanie się zmiana na Windows 7 z powodów, które opisałem w pierwszym punkcie.
    3. OpenCL w wielu przypadkach będzie atrakcyjniejszym wyborem niż DirectCompute do aplikacji ogólnego przeznaczenia: a) OpenCL jest przenośny: Windows XP i nowsze, Mac Os, Linux, b) Wydaje mi się, że OpenCL będzie się szybciej rozwijał, dzięki swoim rozszerzeniom (a różne układy GPU dość dużo się od siebie różnią) i dzięki temu że OpenCL ma niezależny cykl wydawniczy. DirectCompute z kolei zrównuje ze sobą dość różniące się od siebie układy. Przykładowo dla DirectCompute Radeon 4870 to to samo co GeForce GTX280. Jedno i drugie obsługuje tylko ComputeShader 4.0 chociaż układowi NVidii jest bliżej do DirectCompute 5.0.

    „Czy przypadkiem duża konkurencja pomiędzy ati i nvidia nie sprawa że ważniejsze są ich autorskie rozwiązania.”
    ATI nie ma teraz swojego rozwiązania. Brook++ został już praktycznie porzucony a CAL nie jest konkurencją dla OpenCL czy DirectCompute. AMD w zasadzie dość wyraźnie dało sygnał, że największy nacisk kładzie na rozwiązania otwarte czyli właśnie OpenCL i DirectCompute. NVidia również stara się jak najlepiej wspierać OpenCL i DirectX. W zasadzie to oni wcześniej udostępnili odpowiednie sterowniki z jednym i drugim. Jednak NVidia na tym nie poprzestaje, stara się być liderem na rynku GPGPU i można powiedzieć że jej to dobrze wychodzi. CUDA ma kilka funkcji, których nie znajdziemy w rozwiązaniach otwartych. Mamy już dość dojrzałe sterowniki, kolejne wersje profilerów GPU a niedługo dostaniemy kombajn do tworzenia i debugowania aplikacji jako plugin do Visual Studio (zapowiadany Nexus). No i już może za dwie miesiące odbędzie się premiera układu GF100, który według udostępnionych dokumentów technicznych będzie najbardziej zaawansowanym układem GPGPU.

    „Chciałbym przeczytać Pana opinie jak to wszystko wpłynie na systemy operacyjne (czy linux zyska, windows xp straci ird..)”.
    Według mnie niewiele się zmieni, tzn. Windows XP będzie dość szybko umierał śmiercią naturalną, przy lekkiej pomocy ogólnie DirectX11 (a nie samego DirectCompute). Linux dalej będzie zajmował mniej więcej stały udział w rynku.

    PS. Proponuje darowanie sobie „Pana” i przejście na Ty 🙂

  3. „Wydaje mi się, że OpenCL będzie się szybciej rozwijał, dzięki swoim rozszerzeniom”
    Wiesz, to jest z jednej strony zaleta, z drugiej wada. Super, że OGL i OCL mają rozszerzenia i pewne funkcjonalności trafiają szybciej do deweloperów, ale obsługa rozszerzeń będących vendor-specific do najprzyjemniejszej części pisania kodu nie należy. 🙂

  4. ConayR:
    Wydaje mi się jednak, że akurat w przypadku OpenCLa rozszerzenia są plusem. Po pierwsze jak na razie tych rozszerzeń nie jest dużo, po drugie różne układy dość znacznie się różnią. Aktualnie próba unifikacji GPGPU jest skazana na porażkę. Tak jak to wygląda np. z DirectCompute i NVidią. GT200 obsługuje tylko CS 4.0 a niewiele brakuje mu do CS 5.0, podobnie GF100 będzie kompatybilne z CS 5.0 podczas gdy znacznie wykracza poza niego.

Leave a Reply