-
Data: 2013-04-18 16:41:38
Temat: Re: Podpis cyfrowy większej ilości podmiotów
Od: Edek <e...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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
Następne wpisy z tego wątku
- 18.04.13 17:18 M.M.
- 18.04.13 17:35 Edek
- 18.04.13 17:36 bartekltg
- 18.04.13 18:05 firr kenobi
- 18.04.13 18:11 3d
- 18.04.13 22:58 3d
- 18.04.13 23:05 3d
- 19.04.13 20:54 M.M.
- 19.04.13 21:43 firr kenobi
- 20.04.13 09:43 M.M.
- 21.04.13 17:58 Edek
- 21.04.13 19:31 Edek
- 22.04.13 01:26 3d
- 23.04.13 12:13 M.M.
- 23.04.13 20:54 Edek
Najnowsze wątki z tej grupy
- Nowa ustawa o ochronie praw autorskich - opis problemu i szkic ustawy
- Alg. kompresji LZW
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
Najnowsze wątki
- 2025-03-19 China-Kraków => Senior PHP Symfony Developer <=
- 2025-03-19 Kraków => Programista MS Dynamics 365BC/NAV <=
- 2025-03-19 Warszawa => JavaScript / Node / Fullstack Developer <=
- 2025-03-19 Gdańsk => PHP Developer <=
- 2025-03-19 Kraków => MS Dynamics 365BC/NAV Developer <=
- 2025-03-19 Aresztowany na rok "powinien podziękować za to, że miał możliwość przebywania w zakładzie karnym, bo tam jego stan zdrowia się poprawił"
- 2025-03-19 Chrzanów => Specjalista ds. public relations <=
- 2025-03-19 China-Kraków => Key Account Manager IT <=
- 2025-03-19 Wrocław => Konsultant wdrożeniowy Comarch XL (Logistyka, WMS, Produk
- 2025-03-19 Prezydent Duda śmie szkalować bodnaturę niepokalanie poczętą, dwóch pełnomocników Geralda B. i "standardy Tuskie"
- 2025-03-18 Tesla na złom
- 2025-03-18 Ziobrotura 3.0 będzie w prawie przesłuchać "świadka" Tuska bez adwokata w sprawach Sienkiewicza/Bodnara/...?
- 2025-03-18 Produkty ,,Made in Germany" wciąż na topie - art. na www.dw.com
- 2025-03-18 ulaskawienia
- 2025-03-18 Gdynia => Sales Executive / KAM <=