🚀 go-pugleaf

W dniu 2013-04-18 16:41, Edek pisze:
> Dnia Thu, 18 Apr 2013 15:43:37 +0200 po głębokim namyśle bartekltg rzekł:

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


Sam korzystam. Z R sporadycznie, ale z Matlaba znacznie częściej niż
z C++.

Nie chodzi tu o język, a o algorytm - on był tą okrężną drogą.

Samo mnożenie macierzy w Matlabie jest bardzo szybkie,
tak jak najlepszych bibliotek w C++ (ciezko coś rownie
szybkiego napisać ręcznie)



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

Jedynie rzuciłęm uwagę, że w cytowanym przez Ciebie artykule
przyszpieszenie 340 razy jest 'oszustwem', bo porównuje się
wynik dobrego algorytmu w GPU z _niedobrym_ algorytmem na CPU.

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

Korzysta z jakiś grubych bibliotek chyba intela (IMK), więc
podejrzewam, że jest bardzo blisko optymalnej prędkości.


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

Fraktalem jest _brzeg_ zbioru mandelbrota. Duże obszary z dala od
brzegu zachowują się dobrze, a i brzeg nie jest w żadnym razie gęsty
na dużych obszarach. Mówiąc po ludzku, w większości przypadków
jak w x było zielono, to piksel obok też będzie zielono.

Zresztą, popatrz na rysunki, bo to można z rysunków wywnioskować.

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

Witam towarzysza:) Ale racja, dawne czasy.


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

Nadal nie rozumiesz. Nie oszukują na GPU. Oszukują w rozwiązaniu
wzorcowym podając byle jakie.


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

No to weź kod z bloga, wygląda nieźle, i porównaj z którymś
algorytmem wrzuconym tu przez grupowiczów, najlepiej wielowątkowym
i z sse(N).

Nadal obstawiam, żę wynik będzie dość bliski proporcji
przy porównaniu algorytmów dla całych macierzy.
(Pewnie masz inny sprzet, wiec x16 z bloga jest neimiarodajne)

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

Na stronie sprzętowej się nie znam. Chodziło mi o sprawy
geometryczne. JAk chcesz, mogę policzyć, ile strat jest
przy jakich prostokątach, ale to wieczorem, bo muszę znikać;)

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

Nie bardzo rozumiem, o co dokładnie prosisz:( Chyba się zgubiłem.

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

Optymalne wartości czego? Rozmiaru bloku liczonego na raz?

pzdr
bartekltg