Dnia Thu, 18 Apr 2013 15:43:37 +0200 po głębokim namyśle bartekltg rzekł:

> 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ą;)

Wbrew pozorom ludzie faktycznie korzystają z R i Matlaba, wygodne są.

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

Spróbuj nie rozwijać się fraktalnie na temat skutków prośby firra
i zerknij na małe wyzwanie ze świata rzeczywistego. Ja nie mam problemu
z tym, żeby coś w AVX zaimplementować. Czy MatLab jest optymalny czy
nie pod względem SSE tego tak naprawdę nie wiem - przypuszczam znając
dziedzinę od strony implementacyjnej, że _nie_ jest i to grubo.

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

Chodzi Ci o to, że wziąłem przypadkowego bloga i krytykujesz? Ok,
nie mam uwag.

>> Pytanie do Ciebie byłoby takie: jak dobrać ilość/kształt pixeli
>
> Było do mnie jakieś pytanie? :)

Wciąż jest, jeżeli chcesz.

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

"Dość niewielka" - ile to konkretnie wychodzi? I może intuicja mnie
myli, ale fraktale nie zachowują się tak jak Ty to tutaj przedstawiasz.

Ja może nie szpanuję matematyką, bo przez ostatnie lata policzyłem
1 (słownie : jedną) różniczkę, ale masz do czynienia z olimpijczykiem
ze starych czasów, i to Big Time.

Skoro mówisz że oszukują a nie chce Ci się policzyć ile faktycznie
da się wyciągnąć z gpu to dostrzegam tu pewną niekonsekwecję ;)

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

Jasne. A nie policzyłbyś ile to faktycznie wychodzi? Ja oferuję
zmierzenie, żebyś nie musiał za bardzo zakasać rękawów.

>> 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? )

Jest warp, block, grid, multiprocessor i karta z kilkoma MP.

Dlaczego akurat kwadratowe, czy to minimalizuje różnice w iteracjach
w obrębie bloku? Czy przy każdych parametrach? Założenia, dość
realistyczne, podałem.

Bartek: szanuję fakt Twojego popisywania się matematyką, bo dla mnie
masz czym. Czas na mały showdown, polegający na praktycznym zastosowaniu
znajomości podstaw fraktali i zastosowania w algorytmach, o ile masz czas.

Jako okazja występuje Mandelbrot. Nawet nie wiem, czy to o co proszę jest
trudne czy bardzo trudne.

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

No niby tak. Gpu jest przykładem czegoś, po czym można oczekiwać
teoretycznie policzonego wyniku, w przeciwieństwie do Intela
gdzie od p4 w gmp i mpfr można w źródłach znaleźć mięso na
temat nieprzewidywalności pipeline i wydajność jest trudna
do oszacowania.

Skoro już mówimy o Mandelbrocie to fajnie byłoby policzyć
- na podstawie właściwości fraktala - jakie są optymalne
wartości. Mnie ciekawi, czy teoretyczne właściwości tego
prostego algorytmicznie przykładu poz mierzeniu okażą się
prawidłowe na kartach. O to mi chodziło w poprzednim poście,
plus małe wyzwanie.

--
Edek