Jaka przyszłość ma GPU w komputerach? [zamknięte]

Myślę, że można policzyć następny DirectX jako inny sposób korzystania z GPU.

Z mojego doświadczenia wynika, że GPU są niezwykle szybkie dla algorytmów, które są łatwe do paralelizacji. Niedawno zoptymalizowałem specjalny algorytm zmiany rozmiaru obrazu w CUDA, aby był ponad 100 razy szybszy na GPU (nawet nie wysokiej klasy) niż czterordzeniowy procesor Intel. Problem polegał na dostarczeniu danych do GPU, a następnie pobraniu wyniku z powrotem do pamięci głównej, w obu kierunkach ograniczonych przez prędkość memcpy() na tym maszyna, która była mniejsza niż 2 GB / s. w rezultacie algorytm był tylko nieco szybszy niż wersja CPU...

Więc to naprawdę zależy. Jeśli masz aplikację naukową, w której możesz przechowywać większość danych na GPU, a wszystkie algorytmy mapują do implementacji GPU, dobrze. W przeciwnym razie poczekałbym, aż pojawi się szybsza rura między CPU a GPU, albo zobaczmy, co ATI ma w rękawie z połączonym chipem...

O jakiej technologii użyć: myślę, że gdy już masz swoje rzeczy uruchamiając w CUDA, dodatkowy krok do przeniesienia go do OpenCL (lub innego języka) nie jest tak duży. Wykonałeś całą ciężką pracę, porównując swoje algorytmy, a reszta to tylko inny "smak"

Monte Carlo jest żenująco równoległe, ale jest podstawową techniką w informatyce finansowej i naukowej.

Jeden z respondentów jest nieco błędne, aby powiedzieć, że większość realnych wyzwań świata nie są łatwo rozkładać na tego typu zadań.

Wiele śledztw naukowych odbywa się poprzez wykorzystanie tego, co można wyrazić w żenująco równoległy sposób.

To, że nazywa się" żenująco " nie oznacza, że nie jest to skrajnie ważne pole.

Pracowałem w kilku domach finansowych i jesteśmy przekonani, że możemy wyrzucić farmy ponad 1000 silników montecarlo (wiele stosów łopatek ułożonych razem) dla kilku dużych instalacji NVidia CUDA - znacznie zmniejszając koszty energii i ciepła w centrum danych.

Jedną z istotnych korzyści architektonicznych jest to, że jest znacznie mniej obciążenia sieci, ponieważ jest znacznie mniej maszyn, które muszą być dostarczane Dane i raportować swoje wyniki.

Jednak takie technologie są na poziomie abstrakcji niższym niż zarządzany język runtime, taki jak C#, mówimy o urządzeniach sprzętowych, które uruchamiają własny kod na własnych procesorach.

Integracja powinna być najpierw wykonana z Matlab, Mathematica, jak się spodziewałem, wraz z C API oczywiście...

Kolejną technologią, która nadchodzi dla przetwarzania opartego na GPU, są wersje GPU istniejących bibliotek obliczeniowych wysokiego poziomu. Nie bardzo krzykliwe, wiem, ale ma znaczące zalety dla przenośnego kodu i łatwość programowania.

Podobnie Dan Campbell z GTRI pracował nad implementacją CUDA standardu VSIPL do przetwarzania sygnałów. (W szczególności rodzaj przetwarzania sygnału i obrazu, który jest powszechny w systemach radarowych i powiązanych rzeczach, takich jak obrazowanie medyczne.) Znowu jest to standardowy interfejs, a aplikacje, które zostały napisane dla implementacji VSIPL na innych procesorach, mogą być po prostu przekompilowane z tym i używać możliwości GPU w stosownych przypadkach.

W praktyce w dzisiejszych czasach sporo wysokowydajnych programów numerycznych nie wykonuje własnego niskopoziomowego programowania, lecz opiera się na bibliotekach. Na sprzęcie Intela, jeśli robisz number-crunching, generalnie trudno jest pokonać Intel math libraries (MKL) dla większości rzeczy, które implementuje-i korzystanie z nich oznacza, że można uzyskać zalety wszystkich instrukcji wektorowych i sprytnych sztuczek w nowszych procesorów x86, bez konieczności specjalizowania się w ich kodowaniu. Z rzeczy takich jak GPU, podejrzewam, że stanie się to jeszcze bardziej powszechne.

Więc myślę, że technologia do oglądania jest rozwój bibliotek ogólnego przeznaczenia, które tworzą podstawowe bloki konstrukcyjne dla aplikacji w określonych domenach, w sposób, który przechwytuje części tych algorytmów, które mogą być skutecznie wysyłane do GPU, minimalizując ilość nonportable GPU-specific sprytu wymagane od programista.

(Zastrzeżenie Bias: Moja Firma również pracuje nad portem CUDA naszej biblioteki VSIPL++, więc jestem skłonny myśleć, że to dobry pomysł!)

Również, w zupełnie innym kierunku, możesz chcieć sprawdzić niektóre z rzeczy, które RapidMind robi. Ich platforma była początkowo przeznaczona dla wielordzeniowych systemów typu CPU, ale wykonali kawał dobrej roboty, rozszerzając ją również na obliczenia GPU.

Prawie wszystko, co może być równoległe, może przynieść korzyści. Bardziej szczegółowe przykłady to SETI @ home, folding@home i inne rozproszone projekty, a także komputery naukowe.

Szczególnie rzeczy, które w dużym stopniu opierają się na arytmetyce zmiennoprzecinkowej. Dzieje się tak, ponieważ GPU mają wyspecjalizowane obwody, które są bardzo szybkie w operacjach zmiennoprzecinkowych. Oznacza to, że nie jest tak wszechstronny, ale jest bardzo dobry w tym, co robi.

Jeśli chcesz spojrzeć na bardziej dedykowane GPU przetwarzanie, sprawdź NVIDIA Tesla GPU . Jest to GPU, ale nie ma wyjścia monitora!

Wątpię, że zobaczymy zbyt dużo przetwarzania GPU na wspólnym pulpicie, a przynajmniej na jakiś czas, ponieważ nie każdy ma kartę graficzną CUDA lub podobną, jeśli w ogóle ma kartę graficzną. Bardzo trudno jest również uczynić programy bardziej równoległymi. Gry mogłyby wykorzystać tę dodatkową moc, ale będzie to bardzo trudne i prawdopodobnie nie będzie zbyt przydatne, ponieważ wszystkie obliczenia graficzne są w większości już na GPU, a druga praca jest na CPU i mA być na CPU ze względu na zestawy instrukcji.

Przetwarzanie GPU, przynajmniej przez jakiś czas, będzie przeznaczone dla bardzo specyficznych rynków niszowych, które wymagają wielu obliczeń zmiennoprzecinkowych.

Ważne jest, aby pamiętać, że nawet zadania, które są z natury szeregowe, mogą korzystać z równoległości, jeśli muszą być wykonywane wiele razy niezależnie.

Należy również pamiętać, że za każdym razem, gdy ktoś zgłasza przyspieszenie implementacji GPU do implementacji CPU, prawie nigdy nie jest to uczciwe porównanie. Aby być naprawdę sprawiedliwym, programiści muszą najpierw poświęcić czas na stworzenie prawdziwie zoptymalizowanej, równoległej implementacji procesora. Pojedynczy procesor Intel Core i7 965 XE może osiągnąć ok. 70 gigaflopów w podwójnej precyzji. Obecnie wysokiej klasy procesory graficzne mogą wykonywać 70-80 gigaflopów w podwójnej precyzji i około 1000 w pojedynczej precyzji. Tak więc przyspieszenie o więcej niż 15 może oznaczać nieefektywną implementację procesora.

Jednym z ważnych zastrzeżeń w komputerach GPU jest to, że są one obecnie "na małą skalę". Dzięki obiektowi superkomputerowemu można uruchomić równoległy algorytm na setkach, a nawet tysiącach rdzeni procesora. W przeciwieństwie do tego, "klastry" GPU są obecnie ograniczone do około 8 GPU podłączony do jednej maszyny. Oczywiście kilka z tych maszyn może być połączonych ze sobą, ale to dodaje dodatkowej złożoności, ponieważ dane muszą nie tylko przechodzić między komputerami, ale także między procesorami graficznymi. Ponadto, nie ma jeszcze odpowiednika MPI, który pozwala procesom transparentnie skalować do wielu procesorów graficznych na wielu komputerach; musi być ręcznie zaimplementowany (być może w połączeniu z MPI).

Oprócz tego problemu skali, innym głównym ograniczeniem GPU dla obliczeń równoległych jest poważne ograniczenie wzorców dostępu do pamięci. Losowy dostęp do pamięci jest możliwy, ale starannie zaplanowany dostęp do pamięci spowoduje wiele razy lepszą wydajność.

Być może najbardziej obiecującym kandydatem jest Larrabee Intela. Ma znacznie lepszy dostęp do procesora, pamięci systemowej i, być może, co najważniejsze, buforowania. To powinno dać mu znaczne korzyści z wielu algorytmów. Jeśli jednak nie może dorównać ogromnej przepustowości PAMIĘCI na obecnych GPU, może to być pozostaje w tyle za konkurencją dla algorytmów, które optymalnie wykorzystują tę przepustowość.

Obecna generacja sprzętu i oprogramowania wymaga dużo wysiłku programistów, aby uzyskać optymalną wydajność. Często obejmuje to algorytmy restrukturyzacji w celu efektywnego wykorzystania pamięci GPU. Często wiąże się to również z eksperymentowaniem z różnymi podejściami, aby znaleźć najlepszy.

Należy również zauważyć, że wysiłek wymagany do uzyskania optymalnej wydajności jest niezbędny do uzasadnienia korzystania ze sprzętu GPU. Na różnica między naiwną implementacją a zoptymalizowaną implementacją może być rzędu wielkości lub więcej. Oznacza to, że zoptymalizowana impelemntacja procesora będzie prawdopodobnie równie dobra lub nawet lepsza niż naiwna implementacja GPU.

Ludzie już pracują nad wiązaniami. NET dla CUDA. Zobacz tutaj . Jednak z koniecznością pracy na niskim poziomie, nie sądzę, że przetwarzanie GPU jest jeszcze gotowe dla mas.

Słyszałem wiele rozmów o zamianie tego, co dziś są GPU w bardziej ogólne "jednostki proceesor tablicy", do użytku z Dowolny matrix math problem, a nie tylko przetwarzanie grafiki. Nie widziałem jeszcze wiele z tego.

Teoria była taka, że procesory macierzowe mogą podążać mniej więcej tą samą trajektorią, którą procesory zmiennoprzecinkowe podążały kilka dekad wcześniej. Pierwotnie procesory zmiennoprzecinkowe były drogimi dodatkowymi opcjami dla komputerów PC, które nie wielu ludzi pofatygowało się kupować. W końcu stały się tak istotne, że zostały wprowadzone do samego procesora.

Powtórzę odpowiedź, którą dałem tutaj.

Długoterminowo myślę, że GPU przestanie istnieć, ponieważ procesory ogólnego przeznaczenia ewoluują, aby przejąć te funkcje. Larrabee Intela to pierwszy krok. Historia pokazała, że stawianie na x86 to zły pomysł.

Naukowcy GHC (Haskell) (pracujący dla Microsoft Research) dodają obsługę zagnieżdżonego równoległości danych bezpośrednio do ogólnego języka programowania. Chodzi o to, aby używać wielu rdzeni i / lub GPU na zapleczu, a jednocześnie eksponować równoległe macierze danych jako natywny typ w języku, niezależnie od środowiska wykonawczego wykonującego kod równolegle (lub szeregowo dla pojedynczego CPU fallback).

Http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell

W zależności od sukces tego w ciągu najbliższych kilku lat, spodziewałbym się zobaczyć inne języki (w szczególności C#) wychwycić pomysł, który może przynieść tego rodzaju możliwości do bardziej głównego nurtu odbiorców. Być może do tego czasu problemy z przepustowością CPU-GPU i sterownikiem zostaną rozwiązane.

Procesory graficzne działają dobrze w przypadku problemów, w których występuje wysoki poziom równoległości poziomu Danych , co zasadniczo oznacza, że istnieje sposób na podzielenie danych, które mają być przetwarzane, tak aby wszystkie mogły być przetwarzane.

GPU nie są z natury tak szybkie na poziomie taktowania. W rzeczywistości jestem stosunkowo pewien, że prędkość zegara na shaderach (a może mają bardziej GPGPU termin dla nich te dni?) jest dość powolny w porównaniu do ALUs na nowoczesnym procesorze biurkowym. Chodzi o to, że GPU ma absolutnie ogromna ilość tych shaderów, zamieniając GPU w bardzo duży procesor SIMD . Przy takiej ilości shaderów na nowoczesnym Geforce ' u możliwe jest, że GPU pracuje na kilkuset (tysiącach?) liczby zmiennoprzecinkowe na raz.

Tak krótki, że GPU może być niesamowicie szybki w przypadku problemów, w których można poprawnie partycjonować Dane i przetwarzać partycje niezależnie. Nie jest tak potężny na poziomie zadania (wątku) .

Duży problem z technologią GPU polega na tym, że chociaż masz dużo możliwości obliczeniowych, pobieranie danych (i z nich) jest straszne (pod względem wydajności). I uważnie obserwuj wszelkie wskaźniki porównawcze... często porównują gcc (z minimalną optymalizacją, bez wektoryzacji) na pojedynczym procesorze do GPU.

Kolejny duży problem z GPU jest to, że jeśli nie dokładnie myśleć o tym, jak dane są zorganizowane, będzie cierpieć prawdziwy hit wydajności wewnętrznie (w GPU). Często wiąże się to z przepisaniem bardzo prostego kodu na zawiłą stertę śmieci.

Jestem bardzo podekscytowany tą technologią. Myślę jednak, że to tylko zaostrzy prawdziwe wyzwanie dużych zadań równoległych, jednego z pasma. Dodanie większej liczby rdzeni tylko zwiększy zapotrzebowanie na pamięć. OpenCL i inne biblioteki abstrakcji GPGPU nie oferują żadnych narzędzi do poprawy tego.

Każda wysokowydajna platforma sprzętowa obliczeniowa będzie zwykle zaprojektowana z uwzględnieniem kwestii przepustowości starannie zaplanowanej w sprzęcie, równoważenia przepustowości, opóźnień, buforowania i koszt. Tak długo, jak sprzęt towarowy, CPU i GPU, są projektowane w izolacji od siebie, ze zoptymalizowaną przepustowością tylko do ich pamięci lokalnej, będzie bardzo trudno to poprawić dla algorytmów, które tego potrzebują.

To prawda, że GPU może osiągnąć bardzo wysoką wydajność w sytuacjach równoległości poziomu danych, jak wiele tutaj wspomniano. Ale jak widzę, nie ma z tego zbyt wiele pożytku w przestrzeni użytkownika. Nie mogę pomóc w odczuciu, że cała ta propaganda GPGPU pochodzi od producentów GPU, którzy po prostu chcą znaleźć nowe rynki i zastosowania dla swoich produktów. I to absolutnie ok. Czy kiedykolwiek zastanawiałeś się, dlaczego intel / amd nie zawierały niektórych rdzeni mini-x86 oprócz standardowych (powiedzmy-model z czterema x86 rdzenie i 64 mini-x86-rdzenie), tylko po to, by zwiększyć poziom danych? Na pewno mogliby to zrobić, gdyby chcieli. Zgaduję, że przemysł po prostu nie potrzebuje tego rodzaju mocy obliczeniowej w zwykłych komputerach stacjonarnych/serwerowych.

Karty graficzne mogą, ale nie muszą pozostać tak popularne, jak są teraz, ale podstawową ideą staje się dość popularne podejście do przetwarzania dużej mocy. Jednym z trendów, który nadchodzi teraz jest zewnętrzny "akcelerator", aby pomóc procesorowi z dużymi zadaniami zmiennoprzecinkowymi. GPU to tylko jeden rodzaj akceleratora.

Intel wydaje nowy akcelerator o nazwie Xeon Phi , który ma nadzieję rzucić wyzwanie GPU jako akcelerator HPC. Procesor Cell przyjął podobne podejście, mając jeden główny procesor do wykonywania ogólnych zadań i przenoszenia intensywnych zadań obliczeniowych na inne elementy przetwarzania, osiągając imponujące prędkości.

Akceleratory w ogóle wydają się być interesujące w tej chwili, więc powinny być w pobliżu przynajmniej przez jakiś czas. To, czy GPU pozostanie de facto akceleratorem, czy nie, okaże się.

Twoje postrzeganie, że GPU są szybsze niż procesory, opiera się na błędnym przekonaniu stworzonym przez kilka embargoująco równoległych aplikacji stosowanych do sprzętu PS3, NVIDIA i ATI.

Http://en.wikipedia.org/wiki/Embarrassingly_parallel

Większość realnych wyzwań nie jest łatwo rozkładana na tego typu zadania. Procesor stacjonarny jest o wiele lepiej dostosowany do tego typu wyzwań zarówno z punktu widzenia zestawu funkcji, jak i wydajności.

Oczekuję tych samych rzeczy, do których są używane Procesory?

Chodzi mi o to, że wydaje mi się to sztuczką. Waham się powiedzieć "to nigdzie", jeśli chodzi o technologię, ale główną funkcją GPU jest renderowanie grafiki, a główną funkcją procesorów jest wszystkie inne przetwarzanie. To, że GPU robi coś innego, wydaje się dziwne.