🚀 go-pugleaf

Dnia Thu, 18 Apr 2013 14:46:35 +0200 po głębokim namyśle bartekltg rzekł:

> W dniu 2013-04-18 13:13, Edek pisze:
>> http://blogs.mathworks.com/loren/2011/07/18/a-mandelbrot-set-on-the-
gpu/
>>
>> Mówi o 340x szybciej w Matlabie.
> 
> Strasznie tu "oszukują". Porównują kod dla gpu napisany w c++
> wg rozważanego w watku algorytmu (na razie ok) z taką samą iteracją na
> macierzach... ale bez warunku "norma>2 to nie licz dalej"
> i wszystkie piksele mieli maxIterations+1 razy;-) To nasze grupowe
> algorytmy będą od tego kilka-kilkanaście razy szybsze.

Matlab to nie pisanie bezpośrednio na gpu, nawet nie chciało
mi się specjalnie czytać, fir się pytał "ile razy szybciej",
to mu podałem żródło :)

> Bez zmiany algorytmu GPU przyspieszyło im 16 razy,
> i tego rzędu przyspieszenia (z przeczuciem na ciut mniejsze)
> bym się spodziewał w porównaniu cpu/gpu.

Nie wiem jakie masz doświadczenie z gpu, ale tam oszacowuje się
algorytmy przez najniższą z przepustowości - np. nominalnie 
we floatach przepustowość RAM jest ~70 razy mniejsza od obliczeniowej,
zależy oczywiście od tego ile się wczytuje i ile wyników się zapisuje
i czy dostęp do ram jest uszeregowany czy nie.

W Mandelbrot przepustowość RAM jest prawie pomijalna, zostaje 
obliczeniowa. To się naprawdę bierze ze specyfikacji i wychodzi
dokładnie czego się człowiek spodziewa, jeżeli się dobrze policzy.

Obliczeniową liczy się na podstawie Occupancy - jest do tego
kalkulator i profiler. Occupancy jest miarą "zużycia potencjału"
rdzeni - jest kilka ograniczeń typu ilość rejestrów, spills,
liczby blocków i wątków itp. Między innymi w Mandelbrot siłą
rzeczy część pary idzie w gwizdek jeżeli sąsiednie pixele 
policzą się w mniejszej ilośći iteracji, ale ciśnienia
na inne limity nie widzę na dzisiejszych kartach.

I teraz tak: 
mając niezależne pętle dla sąsiednich pixeli przydaje się
instrukcja "any" - jeżeli żaden z wątków nie ma nic do liczenia 
kończy się 16x16 pixeli czy ile ich tam razem będzie optymalnie
sprawdzając po każdej iteracji.

Pytanie do Ciebie byłoby takie: jak dobrać ilość/kształt pixeli 
przetwarzanych razem i jak policzyć ilość marnowanej mocy
obliczeniowej przez blok pixeli, z których część kończy 
iteracje wcześniej, zakladająć że "any" nie kosztuje 
mocy obliczeniowej - inne bloki w tym czasie liczą -
tylko traci się na czas na pixele "już policzone" w bloku.
Założenie trochę naciągane, ale niech będzie.

Serio, takie obliczenie wydajności gpu ma sens. Gpu w 
przeciwieństwie do złożonych Inteli jest przewidywalne.
Zaczęło mieć odchyły tak około GTX 460/465, oczywiście 
w dół.

Ja się nie podejmuję, ale widzę że praktykujesz matmę mocniej
niż ja, więc jak ci się chce to powiedz jak dobrać optymalne
parametry, pewnie na podstawie rozkładów ilości iteracji.
Optymalne wymiary bloku i oszacowanie "strat" przepustowości.
Bo detale doboru funkcji (abs/norm/dzielenie.vs.mnożenie)
i oczekiwanej prezyzji są w instrukcji.

Mogę co najwyżej obiecać, że przetestuję wyniki, to prosty
algorytm.

-- 
Edek