-
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?
Następne wpisy z tego wątku
Najnowsze wątki z tej grupy
- 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
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
Najnowsze wątki
- 2024-12-15 (ino)wrocław
- 2024-12-15 Obcinaczki z łapaczem
- 2024-12-14 światła znów wlączyli
- 2024-12-14 nie lekceważ termostatu
- 2024-12-14 numer 112
- 2024-12-14 Pendrive, ale dysk
- 2024-12-12 Autocom CAN CDP+ wysokie kody błędów
- 2024-12-13 termostat do lodowki
- 2024-12-13 Gdańsk => Inżynier bezpieczeństwa aplikacji <=
- 2024-12-13 Warszawa => Head of International Freight Forwarding Department <=
- 2024-12-13 Poznań => Employer Branding Specialist <=
- 2024-12-13 Kraków => Business Development Manager - Dział Sieci i Bezpieczeńst
- 2024-12-13 Kraków => Business Development Manager - Network and Network Security
- 2024-12-13 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2024-12-13 Gdańsk => Programista Full Stack .Net <=