eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingPodpis cyfrowy większej ilości podmiotówRe: Podpis cyfrowy większej ilości podmiotów
  • 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




Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

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: