-
Data: 2020-03-26 11:53:24
Temat: Re: Wydajność OpenCL
Od: "M.M." <m...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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
Następne wpisy z tego wątku
- 26.03.20 12:12 Mateusz Viste
- 26.03.20 12:37 fir
- 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
- Alg. kompresji LZW
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 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??
Najnowsze wątki
- 2025-03-05 Chiny-Kraków => Backend Developer (Node + Java) <=
- 2025-03-05 Warszawa => JavaScript / Node / Fullstack Developer <=
- 2025-03-05 China-Kraków => Key Account Manager IT <=
- 2025-03-05 China-Kraków => Senior PHP Symfony Developer <=
- 2025-03-05 Gdańsk => Specjalista ds. Sprzedaży <=
- 2025-03-05 Ostrów Wielkopolski => Konsultant Wdrożeniowy Comarch XL/Optima (Ksi
- 2025-03-05 Żerniki => Dyspozytor Międzynarodowy <=
- 2025-03-05 Katowice => Key Account Manager (ERP) <=
- 2025-03-04 Prunt drogi!
- 2025-03-04 Warszawa => Frontend Developer (Angular13+) <=
- 2025-03-04 Warszawa => Frontend Developer (obszar Angular13+) <=
- 2025-03-04 Warszawa => Senior ASP.NET Developer <=
- 2025-03-04 Kraków => MS Dynamics 365BC/NAV Developer <=
- 2025-03-04 Teraz kolej na studentów
- 2025-03-03 Re: Czy to była Polska Dywizja Waffen SS? [SS Galicja]