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

do góry

2020-03-26 o 03:53 -0700, M.M. napisał:
> 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.

Strzelam: przegrzewanie się GPU, stosowny driver informuje o tym
dispatcher, a ten zaczyna przerzucać część zadań na CPU? To czysta
fikcja, bo ja z OpenCL nigdy do czynienia nie miałem, ale warto
monitorować temperatury poszczególnych klocków.

Mateusz

do góry

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

do góry

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?
(a na ilu jakby kanalach rownolegle to kolega zapuszcza?)

do góry

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

do góry

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?

do góry

On 26/03/2020 11:53, M.M. wrote:
> struct Rnd4Lin rnd;

Co to?

do góry

On Thursday, March 26, 2020 at 6:24:21 PM UTC+1, heby wrote:
> On 26/03/2020 11:53, M.M. wrote:
> > struct Rnd4Lin rnd;
>
> Co to?

Struktura do generatora liczb losowych, to złożenie czterech
generatorów liniowych, błędów prawdopodobnie nie ma. I to tutaj
nie ma znaczenia, bo jak upraszczałem kod, to efekt był podobny.
Np. do takiego:

#define N (1000000)
int i,sum=0;
for( i=0 ; i<N ; i++ ) {
sum += foo();
}

Pozdrawiam

do góry