W dniu 2013-04-18 15:24, Edek pisze:
> 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-mandel
brot-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 :)

Ale fir pyał się, ile razy jego auto będzie szybsze,
jeśli domontuje drugi silnik.
Ta strona porównuje do dwusilnikowe auto to ciężarówki,
jadącej okrężną dorogą;)


>> 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.

Nie rozumiesz mnie. Ja nie czepiam się części GPU, ta została
wykonana dobrze. Czepiam się tego, że ten wynik porównano
z innym algorytmem, w doatku absolutnie nieefektywnym na cpu.


> 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.

Ależ ja o tym wiem, doczytaj, o co mi chodzi.

> Pytanie do Ciebie byłoby takie: jak dobrać ilość/kształt pixeli

Było do mnie jakieś pytanie? :)

> 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.

Będzie dość niewielka, bo bliskie obszary w większości przypadków
zachowują się podobnie. Największe straty będą na 'powierzchni'
naszej figury przy dużym maxiter, ale nadal to dośc niewielkia
różnica. Można o tym pomyśleć jak o liczeniu tego samego fraktala
lekko rozpuchniętego.

Z tej samej sztuczki korzystaliśmy dla
mniejszych pakunków korzystając z SSE.
Dlatego przewidywałem nieznacznie mniej niż 16 razy.
Teraz wszytko jasne?


> 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.

Obstawiam, że najlepiej byoby podzielić na obszary możliwie
kwadratowe o rozmiarze takim, by się mieściły w ramach jednego
układu prowadzącego te zależne od siebie obliczenia (zapomnialem
jak się to nazywało, szkolenie z GPU dawno bylo:( blok? )

Hmm, czy tu nie robimy właśnie tego?
kernel.ThreadBlockSize = [kernel.MaxThreadsPerBlock,1,1];
kernel.GridSize = [ceil(numElements/kernel.MaxThreadsPerBlock),1];

pzdr
bartekltg