W dniu 2013-04-18 13:13, Edek pisze:

>>> Hehe, to zależy od karty. Mandelbrot się idealnie zrównolegla, więc
>>>
>>> na karcie z 1 TFlop uzyskuje się praktycznie ~1TFlop. Co tu tworzyć...
>>>
>>>
>>>
>> a przykladowy kod? albo przyklad uruchomienia z podanym czasem wyniku
>> itp ?
>
> Spytaj wuja Gugla, w tej chwili nie zrobię benchmarku.
>
> A zresztą, pierwszy z brzegu link:
>
> 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.


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.


pzdr
bartekltg

do góry

Dnia Thu, 18 Apr 2013 05:01:52 -0700 po głębokim namyśle M.M. rzekł:

> On Thursday, April 18, 2013 1:46:18 PM UTC+2, Edek wrote:
>
>> Oops, korekta. Chyba jednak nie b�dzie dzia�a�, zerkn��em do
>> cpuinfo.
>> Ale mo�e kto� albo sprawdzi albo uwierzy na s�owo tudzie�
>> wynik "time". Mo�na te� w prosty spos�b zamieni� instrinsici na
>> kr�tsze ni� 256bit.
>
> Nawet nie chce się u mnie to skompilować. Ale oczywiście wierzę.

Tak, sprawdziłem. Nie wiem dlaczego, ale oczekiwałem że gcc zaemuluje
brakujące intrinsics. Cóż, moja wada. Da się skompilować z odpowiednim
-march, pytanie tylko po co.

> Najważniejsze pytanie w tym wątku, czy można generalizować te wyniki na
> inne programy?

Nie wiem. Nigdy nie pisałem w avx ani sse. Chciałem sprawdzić, czy umiem
i jak mi pójdzie, mogłem poświęcić te dwie godziny. Kiedyś pamiętam
rozmawialiśmy o nn na cuda i nie chciałeś zakumać po co to robię i
dlaczego, a to było podobnie - nn się fajnie zrównoleglają. Ale wystarczy
inna topologia i trzeba zacząć kombinować gorzej niż w tych szachach.

--
Edek

do góry

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

> 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

do góry

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

do góry

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

do góry

On Thursday, April 18, 2013 3:02:07 PM UTC+2, Edek wrote:

> > Najważniejsze pytanie w tym wątku, czy można generalizować te wyniki na
> > inne programy?
>
> Nie wiem. Nigdy nie pisałem w avx ani sse.
Wygląda na to, że od czasu do czasu zdarzają się aplikacje, w których
można uzyskać znaczną poprawę wydajności gdy się użyje asemblera.


> Chciałem sprawdzić, czy umiem i jak mi pójdzie, mogłem poświęcić te
> dwie godziny.
Nom ładnie poszło, gratuluję. Chyba też poszukam jakiegoś przejrzystego
tutoriala o SSE i krewnych.


> Kiedyś pamiętam rozmawialiśmy o nn na cuda i nie chciałeś zakumać po
> co to robię i dlaczego, a to było podobnie - nn się fajnie zrównoleglają.
Ja pamiętam, że pisałeś iż uruchamianie NN to marnowanie cudy, ale pewnie
coś pomyliłem po takim czasie. Kiedyś czytałem jakiś artykuł, pisali tam,
że uzyskali przyspieszenie 260 w CUDA na sieciach neuronowych. Porównywali
z sobą 2 CPU intela vs 4 GPU, nie pamiętam szczegółów, ale wyglądało
jakby wzięli na owe czasy najnowsze GPU i CPU. Też uważam że zwykle NN
idealnie się zrównolegla.


> Ale wystarczy inna topologia i trzeba zacząć kombinować gorzej niż w
> tych szachach.
Pomimo wad kompilatory będą jeszcze długo w użytku ;-)

Pozdrawiam

do góry

Dnia Thu, 18 Apr 2013 08:18:36 -0700 po głębokim namyśle M.M. rzekł:

> On Thursday, April 18, 2013 3:02:07 PM UTC+2, Edek wrote:
>
>> > Najważniejsze pytanie w tym wątku, czy można generalizować te wyniki
>> > na inne programy?
>>
>> Nie wiem. Nigdy nie pisałem w avx ani sse.
> Wygląda na to, że od czasu do czasu zdarzają się aplikacje, w których
> można uzyskać znaczną poprawę wydajności gdy się użyje asemblera.

Assembler jest z kategorii hardcore.

>> Chciałem sprawdzić, czy umiem i jak mi pójdzie, mogłem poświęcić te
>> dwie godziny.
> Nom ładnie poszło, gratuluję. Chyba też poszukam jakiegoś przejrzystego
> tutoriala o SSE i krewnych.

A dzięki, ale ja to robiłem na drapaka, czyli jak to się ładniej mówi
"crash course".

>> Kiedyś pamiętam rozmawialiśmy o nn na cuda i nie chciałeś zakumać po co
>> to robię i dlaczego, a to było podobnie - nn się fajnie zrównoleglają.
> Ja pamiętam, że pisałeś iż uruchamianie NN to marnowanie cudy, ale
> pewnie coś pomyliłem po takim czasie. Kiedyś czytałem jakiś artykuł,
> pisali tam,
> że uzyskali przyspieszenie 260 w CUDA na sieciach neuronowych.
> Porównywali z sobą 2 CPU intela vs 4 GPU, nie pamiętam szczegółów, ale
> wyglądało jakby wzięli na owe czasy najnowsze GPU i CPU. Też uważam że
> zwykle NN idealnie się zrównolegla.

No bo nie mam zbyt wysokiego mniemania o NN w sensie ogólnym. Jak to
mówią ludzie z front-office, fajnie działają, ale nie da się tego
sprzedać, bo to black-box - na pytanie "jak to działa w konkretnym
przypadku" można rybkę szczelić.

Dodatkowo NN to artefakt ideologii AI, gdzie mapowanie mózgu przesłania
mapowanie umysłu, a tu już się kłania lingwistyka.

Praktycznie ja najpierw zrobiłem typowe NN, gdzie zrównoleglanie było
banalne, a potem zrobiłem coś takiego:

- - - - -
|/\/|\/|/\ |/ \|
- - - - -

I to już zaczęlo mnie uczyć kombinowania w programowaniu gpu. Naprawdę
trzeba się namęczyć.

>> Ale wystarczy inna topologia i trzeba zacząć kombinować gorzej niż w
>> tych szachach.
> Pomimo wad kompilatory będą jeszcze długo w użytku ;-)

I Bobrowi Nazarejskiemu za to dzięki, płaci za pizzę :)

--
Edek

do góry

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

do góry

>
>
> for( i=0 ; i {
> y = 2.0 * x * y + _y;
> x = xx - yy + _x;
> xx = x*x;
> yy = y*y;
> if (xx+yy>4.0) break;
>
> }

no jest to bazowa wersja
(z tym ze y = (x + x) * y + _y;)
z trzema mnozeniami i jednym
porownaniem

glownie interesuje mnie czy
wersja z dwoma mnozeniami

for()
{
reim2 = (re + re) * im;
re = (re - im) * (re + im) + cRe;
im = reim2 + cIm;

if( re > 2.0 || re<-2.0 || im> 2.0 || im<-2.0 ) break;

}

i czterema porownaniami mialaby miec szanse byc szybszą np po rozwinieciu - sprawdze
pewnie wieczorem albo jutro

do góry

W ciemnym zaułku dnia Thu, 18 Apr 2013 17:36:02 +0200, bartekltg
<b...@g...com> wymamrotal:
> Korzysta z jakiś grubych bibliotek chyba intela (IMK), więc
> podejrzewam, że jest bardzo blisko optymalnej prędkości.

Hej, jako koleś z backoffice powiem: tak to się sprzedaje, dokładnie
tak jak "340 ray szybsze". Jasne, spora część jest optymalna.


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

Ok, zbiór, algebra, obrazki. To jest podłoże do stwierdzenia, że
liczby iteracji są zbliżone lokalnie w części powierzchni. Gdyby
to oszacować jeszcze rozsądnie.

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

Dokładnie.


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

No a czego się spodziewać po x razy szybciej na gpu, gdzie "gpu"
oznacza kartę od wbudowanych i z ram cpu do entuzjastycznych?
Miło że dostrzegasz ideę, ale na blogach tego typu ogranicza się
detale i "popularyzuje", czyli upraszcza. Jakbyś tego nie wiedział
załóz rozsądnego bloga.

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

O, no to właśnie.

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

Policz.

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

Tak. I strat przepustowości, żeby precyzyjnie odpowiedzieć,
jaką wydajność będzie miał algorytm. To jedno i to samo,
pewnie trzeba szacować.

--
3d

do góry