-
Data: 2020-03-26 12:37:37
Temat: Re: Wydajność OpenCL
Od: fir <p...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie 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
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 <=