eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingPodpis cyfrowy większej ilości podmiotów
Ilość wypowiedzi w tym wątku: 101

  • 81. Data: 2013-04-18 14:46:35
    Temat: Re: Podpis cyfrowy większej ilości podmiotów
    Od: bartekltg <b...@g...com>

    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




  • 82. Data: 2013-04-18 15:02:07
    Temat: Re: Podpis cyfrowy większej ilości podmiotów
    Od: Edek <e...@g...com>

    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


  • 83. Data: 2013-04-18 15:24:56
    Temat: Re: Podpis cyfrowy większej ilości podmiotów
    Od: Edek <e...@g...com>

    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


  • 84. Data: 2013-04-18 15:43:37
    Temat: Re: Podpis cyfrowy większej ilości podmiotów
    Od: bartekltg <b...@g...com>

    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



  • 85. Data: 2013-04-18 16:41:38
    Temat: Re: Podpis cyfrowy większej ilości podmiotów
    Od: Edek <e...@g...com>

    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





  • 86. Data: 2013-04-18 17:18:36
    Temat: Re: Podpis cyfrowy większej ilości podmiotów
    Od: "M.M." <m...@g...com>

    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


  • 87. Data: 2013-04-18 17:35:15
    Temat: Re: Podpis cyfrowy większej ilości podmiotów
    Od: Edek <e...@g...com>

    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


  • 88. Data: 2013-04-18 17:36:02
    Temat: Re: Podpis cyfrowy większej ilości podmiotów
    Od: bartekltg <b...@g...com>

    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





  • 89. Data: 2013-04-18 18:05:13
    Temat: Re: Podpis cyfrowy większej ilości podmiotów
    Od: firr kenobi <p...@g...com>

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


  • 90. Data: 2013-04-18 18:11:17
    Temat: Re: Podpis cyfrowy większej ilości podmiotów
    Od: 3d <d...@...niebie>

    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

strony : 1 ... 8 . [ 9 ] . 10 . 11


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: