eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingWydajność OpenCLRe: Wydajność OpenCL
  • X-Received: by 2002:a05:6214:a02:: with SMTP id dw2mr7931696qvb.74.1585228947593;
    Thu, 26 Mar 2020 06:22:27 -0700 (PDT)
    X-Received: by 2002:a05:6214:a02:: with SMTP id dw2mr7931696qvb.74.1585228947593;
    Thu, 26 Mar 2020 06:22:27 -0700 (PDT)
    Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!3.eu.feeder.erj
    e.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!82.197.223.10
    6.MISMATCH!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.160.216.MISMATCH!news
    -out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.
    com!not-for-mail
    Newsgroups: pl.comp.programming
    Date: Thu, 26 Mar 2020 06:22:27 -0700 (PDT)
    In-Reply-To: <e...@g...com>
    Complaints-To: g...@g...com
    Injection-Info: google-groups.googlegroups.com; posting-host=5.172.255.31;
    posting-account=Sb6m8goAAABbWsBL7gouk3bfLsuxwMgN
    NNTP-Posting-Host: 5.172.255.31
    References: <c...@g...com>
    <3...@g...com>
    <r5dhol$h0v$1@dont-email.me>
    <3...@g...com>
    <r5dqug$sic$1@dont-email.me>
    <8...@g...com>
    <f...@g...com>
    <f...@g...com>
    <e...@g...com>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <8...@g...com>
    Subject: Re: Wydajność OpenCL
    From: fir <p...@g...com>
    Injection-Date: Thu, 26 Mar 2020 13:22:27 +0000
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable
    Xref: news-archive.icm.edu.pl pl.comp.programming:214805
    [ ukryj nagłówki ]

    W dniu czwartek, 26 marca 2020 13:57:36 UTC+1 użytkownik M.M. napisał:
    > On Thursday, March 26, 2020 at 12:40:49 PM UTC+1, fir wrote:
    > > W dniu czwartek, 26 marca 2020 12:37:39 UTC+1 użytkownik fir napisał:
    > > > W dniu czwartek, 26 marca 2020 11:53:26 UTC+1 użytkownik M.M. napisał:
    > > > > On Tuesday, March 24, 2020 at 9:35:30 PM UTC+1, heby wrote:
    > > > > > On 24/03/2020 21:19, M.M. wrote:
    > > > > > > dojdzie - ale pewności nie mam. Szykuję się do napisania kilku
    > > > > > > kolejnyhch mikro programików do dalszych testów.
    > > > > >
    > > > > > Zainteresuja się książkami do OpenCL i CUDA. Są dostępne w PL i dość
    > > > > > jasno tłumaczą ograniczenia architektur obu technologii (w sumie są to
    > > > > > ograniczenia identyczne).
    > > > > >
    > > > > > > Czy coś mniej lub bardziej ważnego zapomniałem?
    > > > > >
    > > > > > Najzwyczajniej poszukaj literatury. Algorytmika stosowana w OpenCL/Cuda
    > > > > > jest inna niż w normalnym programowaniu imperatywnym na CPU. To jest od
    > > > > > dawna rozpracowane, nie musisz szukać np. metody sortowania, są gotowe
    > > > > > algorytmy które albo są optymalne dla tej organizacji albo są bliskie.
    > > > > >
    > > > > > >> A potrafisz napisać algorytm który poprawnie (tzn blisko optymalnego)
    > > > > > >> syntezuje się na FPGA? Co prawda prawie każdy kod w języka HDL można
    > > > > > >> zsyntezować, ale zdecydowanie nie każdy powinno się syntezować.
    > > > > > > Jestem laikiem w tej dziedzinie, przeczytałem na wyrywki jedną
    przypadkową
    > > > > > > pracę znalezioną w internecie na ten temat. Ktoś opisywał, że poniższy
    > > > > > > algorytm (SHIFT) na FPGA/ASIC można zrobić w jednym takcie:
    > > > > > > for( i=256 ; i>0 ; i-- ) {
    > > > > > > tab[i] = tab[i-1];
    > > > > > > }
    > > > > >
    > > > > > Taka pętla na FPGA nie istnieje. Zostaje zsyntezowana do "czegoś" co
    > > > > > dalece odbiega od pętli. I niekoniecznie wyrazi to co chciał uzyskać
    > > > > > autor. Być może zostanie rozbita na 256*x przerzutników a być może wcale
    > > > > > nic nie jest potrzebne bo można zastosować multipleksery wiec wychodzi
    > > > > > układ kombinacyjny. To czy syntezer dobrze to zrozumie i dobrze
    > > > > > zsyntezuje jest kłopotliwe i języki C-like niespecjalnie nadają się do
    > > > > > wyrażenia tego przez programistę. W FPGA sekwencyjność wyrażana jest w
    > > > > > inny sposób niż linia po lini kodu źródłowego, preferuje się
    > > > > > programowanie eventowe, podaje hinty jak coś ma działać, niektóre
    > > > > > konstrukcje równoleglają się same mimo że nie widać tego w kodzie itd itp.
    > > > > >
    > > > > > > Na GPU i na CPU (chyba) taka optymalizacja nie jest możliwa, i to bez
    względu
    > > > > > > na ilość rdzeni. Czy kompilatory OpenCL potrafią takie algorytmy
    efektywnie
    > > > > > > skompilować na FPGA/ASIC - nie mam pojęcia.
    > > > > >
    > > > > > Z róznych opisów tu i tam wynika że nie potrafią w tej chwili
    > > > > > optymalizować tego typu rzeczy w sposób bliski optymalnemu. Nie oznacza
    > > > > > to że robią złą robotę, ale programista HDL jest w stanie wyrazić
    > > > > > sensowniej co chce bo ma do dyspozycji niższe poziomy abstrakcji do
    > > > > > sprzętu. Wygląda na to że technologia jest jeszcze nie do końca sensowna
    > > > > > i jest wątpliwość czy pisanie na FPGA w jakimś dialekcie C z OpenCL jest
    > > > > > prawidłowym kierunkiem. Być może pojawi się jakiś inny język w OpenCL
    > > > > > który pozwoli na detaliczność opisu taką jak daje VHDL czy Verilog.
    > > > >
    > > > >
    > > > > Chyba naprawdę będę musiał coś poczytać o OpenCL, czasami widzę dziwne
    > > > > zachowanie w prostych programach. Gdy na GPU są wykonywane jakieś proste
    > > > > obliczenia w pętli, np. suma losowych liczb:
    > > > >
    > > > > __kernel void OpenCLPi(__global struct Worker const* workers, const ulong
    n_loops) {
    > > > > struct Worker *const worker = workers + get_global_id(0);
    > > > > struct Rnd4Lin rnd;
    > > > > seed( &rnd, worker->seed );
    > > > > ulong count = 0;
    > > > > for( ulong i=0 ; i<n_loops ; i++ ) {
    > > > > count += getRnd( &rnd ) & 0xFF;
    > > > > }
    > > > > worker->count = count;
    > > > > }
    > > > >
    > > > > To po zwiększeniu ilości pętli (parametr n_loops) z 1mln do 2mln czas
    > > > > obliczeń wzrasta liniowo dwa razy. Gdy zwiększam do 4 mln to też
    > > > > zgodnie z oczekiwaniami czas obliczeń wzrasta 4 razy. I to się
    > > > > sprawdza gdzieś do około 10mln. Gdy ilość pętli jest równa 10mln to
    > > > > czas wydłuża się 10-krotnie. Natomiast gdy zwiększam do 20mln to w
    > > > > ogóle nie mogę doczekać się końca obliczeń, a gdy przerwę program po
    > > > > długim czasie, to w statystykach widzę, że dużo obliczeń było
    > > > > wykonywanych na CPU. Nie wiem z czego to wynika, czas powinien wzrastać
    > > > > liniowo, bo liniowo wzrasta ilość pętli.
    > > > >
    > > > > Pozdrawiam
    > > >
    > > > tez nie wiem (sam opencl uzywalem kilka lat temu przez pare dni jak wspominam
    uznajac ze ciekawe ale mam pilniejsze sprawy)- o ile pamietam jednak w setupie opencl
    mozna przydzielic chyba jakie
    > > > sprzety maja wykonywac kod i pewnie cpu mozna wylaczyc (?)
    > > >
    > > > w sumie dobrze ze kolega ten temat postuje moze i kiedys bym sie w to troche
    wkrecil
    > > >
    > > > jest tez opcja ze jest to jakis bug w kodzie i jednak ta liczba 20 mln cos
    zmienia.. prosty wniosek ze np debugujac top trzeba eksperymentalnie pozmieniac pare
    rzeczy i sprawdzic od czego to dokladniej zalezy
    > >
    > > wogole to oopencl moglby chyab zwolnic kiedy zasoby by sie wyczerpaly (np ilosc
    wewnetrznych kanalow/watkow lyb pamiec robiocza) wtedy pewnie mogloby spasc
    > > do poziomu wykjonywania o klase wolniej
    > > ale tutaj nie wiem czy to moze wystepowac
    > >
    > > to co kolega nazywa "iloscia petli" to ilosc obrotow w zwyklej petli czyz nie?
    >
    > Po prostu, jest prosty kod:
    >
    > #define N (1000000)
    > int i,sum=0;
    > for( i=0 ; i<N ; i++ ) {
    > sum += foo();
    > }
    >

    no mneij wiecej widze, tylko wyrazenie "ilosc petli" jest raczej dziwne na takie cos
    bo zwykle jesli chodzi o ilosc petli tto sie ma na mysli dwie petle, trzy petle itd

    > To czas wykonania liniowo zmienia się wraz ze zmianą parametru N, ale
    > pod warunkiem gdy N jest w przedziale gdzieś od zera do 10mln. Gdy
    > zwiększam N=20mln to czas wzrasta tak mocno, że ubijam proces przez
    > ctrl+c, a w statystykach mam że procesor był mocno używany - a kod jest
    > kompilowany na GPU. W OpenMP mam identyczne wyniki i nie mam problemu.
    >
    >
    > > (a na ilu jakby kanalach rownolegle to kolega zapuszcza?)
    > Podaję tylko ilość zadań i oczekuję że OpenCL i OpenMP sam
    > podzieli to na optymalną ilość wątków. W OpenMP to działa.
    >
    >
    ale ile jest tych 'zadan'? mozna by tez sprawdzic przy jakiej dokladnie liczbie to
    spada, bo powiedzenie 10 mln 20 mln niezbyt dokladne... moze to jakas znaczaca
    charakterystyczna liczba?

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

  • 26.03.20 18:24 heby
  • 26.03.20 18:57 M.M.

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: