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();
}

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.


Pozdrawiam