eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingWydajność OpenCL › Re: Wydajność OpenCL
  • X-Received: by 2002:a05:6214:11f4:: with SMTP id e20mr7710858qvu.66.1585222657798;
    Thu, 26 Mar 2020 04:37:37 -0700 (PDT)
    X-Received: by 2002:a05:6214:11f4:: with SMTP id e20mr7710858qvu.66.1585222657798;
    Thu, 26 Mar 2020 04:37:37 -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!tr1.eu1.usene
    texpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.d
    ca1.giganews.com!nntp.giganews.com!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 04:37:37 -0700 (PDT)
    In-Reply-To: <8...@g...com>
    Complaints-To: g...@g...com
    Injection-Info: google-groups.googlegroups.com; posting-host=5.172.255.21;
    posting-account=Sb6m8goAAABbWsBL7gouk3bfLsuxwMgN
    NNTP-Posting-Host: 5.172.255.21
    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>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <f...@g...com>
    Subject: Re: Wydajność OpenCL
    From: fir <p...@g...com>
    Injection-Date: Thu, 26 Mar 2020 11:37:37 +0000
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable
    Lines: 133
    Xref: news-archive.icm.edu.pl pl.comp.programming:214802
    [ ukryj nagłówki ]

    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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

  • 26.03.20 12:40 fir
  • 26.03.20 13:57 M.M.
  • 26.03.20 14:22 fir
  • 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: