Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #33806 > unrolled thread

Wydajność OpenCL

Back to article view | Back to pl.comp.programming

Contents

  Wydajność OpenCL "M.M." <mmarszik@gmail.com> - 2020-03-18 05:34 -0700
    Re: Wydajność OpenCL fir <profesor.fir@gmail.com> - 2020-03-21 03:17 -0700
      Re: Wydajność OpenCL "M.M." <mmarszik@gmail.com> - 2020-03-21 13:10 -0700
      Re: Wydajność OpenCL "M.M." <mmarszik@gmail.com> - 2020-03-21 15:05 -0700
    Re: Wydajność OpenCL "M.M." <mmarszik@gmail.com> - 2020-03-22 12:34 -0700
      Re: Wydajność OpenCL fir <profesor.fir@gmail.com> - 2020-03-22 16:53 -0700
        Re: Wydajność OpenCL "M.M." <mmarszik@gmail.com> - 2020-03-22 17:37 -0700
      Re: Wydajność OpenCL heby <heby@poczta.onet.pl> - 2020-03-24 18:58 +0100
        Re: Wydajność OpenCL "M.M." <mmarszik@gmail.com> - 2020-03-24 13:19 -0700
          Re: Wydajność OpenCL heby <heby@poczta.onet.pl> - 2020-03-24 21:35 +0100
            Re: Wydajność OpenCL "M.M." <mmarszik@gmail.com> - 2020-03-26 03:53 -0700
              Re: Wydajność OpenCL Mateusz Viste <mateusz@xyz.invalid> - 2020-03-26 12:12 +0100
              Re: Wydajność OpenCL fir <profesor.fir@gmail.com> - 2020-03-26 04:37 -0700
                Re: Wydajność OpenCL fir <profesor.fir@gmail.com> - 2020-03-26 04:40 -0700
                  Re: Wydajność OpenCL "M.M." <mmarszik@gmail.com> - 2020-03-26 05:57 -0700
                    Re: Wydajność OpenCL fir <profesor.fir@gmail.com> - 2020-03-26 06:22 -0700
              Re: Wydajność OpenCL heby <heby@poczta.onet.pl> - 2020-03-26 18:24 +0100
                Re: Wydajność OpenCL "M.M." <mmarszik@gmail.com> - 2020-03-26 10:57 -0700

#33806 — Wydajność OpenCL

Napisałem i uruchomiłem minimalistyczny programik w
OpenCL żeby zobaczyć, jakie w praktyce można uzyskać przyspieszenie.

Program wykonywał obliczenia minimalistyczne na int32, byle
coś liczył, link do kodu:
https://github.com/mmarszik/OpenCLArrProcess00

U mnie OpenCL działa 67 razy szybciej względem obliczeń na jednym 
rdzeniu procesora, czyli względem całego procesora około 30 razy.
Procesor i5, GPU: intel HD 5500. Czyli na przeciętnej karcie
graficznej (np. gtx 1650, która zużywa tylko 75wat mocy) można
uzyskać przyspieszenie 450 razy względem procesora i5, a na 
najnowszych GPU około 1150 razy i 30 razy względem najnowszych
procesorów (takich jak AMD Ryzen Threadripper 3990X)

Prawdę powiedziawszy, myślałem że przyspieszenie będzie w 
granicach 50-100 razy jeśli GPU i CPU są w tej samej klasie
cenowej.

Może obliczenia dotyczyczące grafiki 2-3D by dały przyspieszenie
rzędu 50-100 razy. Ciekawe też, dlaczego jak coś renderuję w
blenderze to przyspieszenie mam nie większe niż 10 razy. Pewnym 
mankamentem jest to, że procesor może mieć dziś (łatwo i tanio) dostęp 
do np. 128GB RAM, a GPU rzadko ma powyżej 8GB, ale za to do jednej płyty
głównej można podpiąć dużo GPU (już widziałem 8).


Tu więcej o sprzęcie na jakim uruchomiłem test:


cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 61
model name	: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping	: 4
microcode	: 0x2e
cpu MHz		: 1093.559
cache size	: 3072 KB
...............................


lshw -C display
  *-display                 
       description: VGA compatible controller
       product: HD Graphics 5500
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 09
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:48 memory:c0000000-c0ffffff memory:b0000000-bfffffff ioport:5000(size=64) memory:c0000-dffff

[toc] | [next] | [standalone]

#33807

W dniu środa, 18 marca 2020 13:34:38 UTC+1 użytkownik M.M. napisał:
> Napisałem i uruchomiłem minimalistyczny programik w
> OpenCL żeby zobaczyć, jakie w praktyce można uzyskać przyspieszenie.
> 
> Program wykonywał obliczenia minimalistyczne na int32, byle
> coś liczył, link do kodu:
> https://github.com/mmarszik/OpenCLArrProcess00
> 
> U mnie OpenCL działa 67 razy szybciej względem obliczeń na jednym 
> rdzeniu procesora, czyli względem całego procesora około 30 razy.
> Procesor i5, GPU: intel HD 5500. Czyli na przeciętnej karcie
> graficznej (np. gtx 1650, która zużywa tylko 75wat mocy) można
> uzyskać przyspieszenie 450 razy względem procesora i5, a na 
> najnowszych GPU około 1150 razy i 30 razy względem najnowszych
> procesorów (takich jak AMD Ryzen Threadripper 3990X)
> 
> Prawdę powiedziawszy, myślałem że przyspieszenie będzie w 
> granicach 50-100 razy jeśli GPU i CPU są w tej samej klasie
> cenowej.
> 
> Może obliczenia dotyczyczące grafiki 2-3D by dały przyspieszenie
> rzędu 50-100 razy. Ciekawe też, dlaczego jak coś renderuję w
> blenderze to przyspieszenie mam nie większe niż 10 razy. Pewnym 
> mankamentem jest to, że procesor może mieć dziś (łatwo i tanio) dostęp 
> do np. 128GB RAM, a GPU rzadko ma powyżej 8GB, ale za to do jednej płyty
> głównej można podpiąć dużo GPU (już widziałem 8).
> 
> 
> Tu więcej o sprzęcie na jakim uruchomiłem test:
> 
> 
> cat /proc/cpuinfo 
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 61
> model name	: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
> stepping	: 4
> microcode	: 0x2e
> cpu MHz		: 1093.559
> cache size	: 3072 KB
> ...............................
> 
> 
> lshw -C display
>   *-display                 
>        description: VGA compatible controller
>        product: HD Graphics 5500
>        vendor: Intel Corporation
>        physical id: 2
>        bus info: pci@0000:00:02.0
>        version: 09
>        width: 64 bits
>        clock: 33MHz
>        capabilities: msi pm vga_controller bus_master cap_list rom
>        configuration: driver=i915 latency=0
>        resources: irq:48 memory:c0000000-c0ffffff memory:b0000000-bfffffff ioport:5000(size=64) memory:c0000-dffff

mw potwierdza to moje wyobrazenie/oszaowania jakie sobie wyrobilem na podstawie moich testow i czytania netu pare lat temu

w pewnym sensie sa to dobre wiesci bo znaczy ze jak ktos bardzo potrzebuje tej mocy obliczeniowej to moze z kart pewnie aporo wycisnac

co prawda ja dodam nie spoedziewalbym sie 
50-100 x wiekszej mocy w kategoriach 'tej samej polki cenowej' raczej bym sie sposdziewal powiedzmy 5-27 ale to tez jest sporo

kwestia jest jednak tak czym sie kto zajmuje jesli ja zajmuje sie ogolnym
programowaniem to teraz dla mnei bardziej liczy sie prostota, wygioda i 'krzepkosc' programu i programowania niz optymalizacje (nawet ciekawych, naukowych) hello worldów

obecnie nieststy wlacze z wlasną motywacja, kalendażem na scianie i problemami zdrowotno zyciowymi
(a jak juz nad czyms pracuje to troche dropnalem ambitniejsze projekty 2d/3d 
i jak juz to zajmuje sie swoimi prostymi
tematami asemblerem, kompilatorem i edytorem kodu - bo sa to w porownaniu z ambitnymi rzeczami w sumie rzeczy wzglednie proste, i jak widac niewiele do nich trzeba (poza tonami motywacji))

[toc] | [prev] | [next] | [standalone]

#33808

On Saturday, March 21, 2020 at 11:17:27 AM UTC+1, fir wrote:
> mw potwierdza to moje wyobrazenie/oszaowania jakie sobie wyrobilem na podstawie moich testow i czytania netu pare lat temu
> 
> w pewnym sensie sa to dobre wiesci bo znaczy ze jak ktos bardzo potrzebuje tej mocy obliczeniowej to moze z kart pewnie aporo wycisnac

> 
> co prawda ja dodam nie spoedziewalbym sie 
> 50-100 x wiekszej mocy w kategoriach 'tej samej polki cenowej' raczej bym sie sposdziewal powiedzmy 5-27 ale to tez jest sporo

Słyszałem że można uzyskać przyspieszenie 300 razy (w tej samej klasie
cenowej) jeśli operuje się ściśle na grafice.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#33810

On Saturday, March 21, 2020 at 11:17:27 AM UTC+1, fir wrote:

> kwestia jest jednak tak czym sie kto zajmuje jesli ja zajmuje sie ogolnym
> programowaniem to teraz dla mnei bardziej liczy sie prostota, wygioda i 'krzepkosc' programu i programowania niz optymalizacje (nawet ciekawych, naukowych) hello worldów

Niestety, optymalizowanie jest zaprzeczeniem prostoty, wygody, 
elastyczności, itd. Ale w tej samej cenie co procesor można
uzyskać przyspieszenie rzędu 30 razy, a na przetwarzaniu grafiki i
wektorów zapewne jeszcze większe. Potem nie trzeba dokupować
siedem komputerów, tylko siedem kart GPU i można mieć przyspieszenie 
200 razy, a pisanie równoległego oprogramowania i w dodatku na klaster 
też nie jest takie łatwe. Może czasami warto... 

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#33811

On Wednesday, March 18, 2020 at 1:34:38 PM UTC+1, M.M. wrote:
> Napisałem i uruchomiłem minimalistyczny programik w
> OpenCL żeby zobaczyć, jakie w praktyce można uzyskać przyspieszenie.
> 
> Program wykonywał obliczenia minimalistyczne na int32, byle
> coś liczył, link do kodu:
> https://github.com/mmarszik/OpenCLArrProcess00
> 
> U mnie OpenCL działa 67 razy szybciej względem obliczeń na jednym 
> rdzeniu procesora, czyli względem całego procesora około 30 razy.
> Procesor i5, GPU: intel HD 5500. Czyli na przeciętnej karcie
> graficznej (np. gtx 1650, która zużywa tylko 75wat mocy) można
> uzyskać przyspieszenie 450 razy względem procesora i5, a na 
> najnowszych GPU około 1150 razy i 30 razy względem najnowszych
> procesorów (takich jak AMD Ryzen Threadripper 3990X)
> 
> Prawdę powiedziawszy, myślałem że przyspieszenie będzie w 
> granicach 50-100 razy jeśli GPU i CPU są w tej samej klasie
> cenowej.
> 
> Może obliczenia dotyczyczące grafiki 2-3D by dały przyspieszenie
> rzędu 50-100 razy. Ciekawe też, dlaczego jak coś renderuję w
> blenderze to przyspieszenie mam nie większe niż 10 razy. Pewnym 
> mankamentem jest to, że procesor może mieć dziś (łatwo i tanio) dostęp 
> do np. 128GB RAM, a GPU rzadko ma powyżej 8GB, ale za to do jednej płyty
> głównej można podpiąć dużo GPU (już widziałem 8).
> 
> 
> Tu więcej o sprzęcie na jakim uruchomiłem test:
> 
> 
> cat /proc/cpuinfo 
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 61
> model name	: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
> stepping	: 4
> microcode	: 0x2e
> cpu MHz		: 1093.559
> cache size	: 3072 KB
> ...............................
> 
> 
> lshw -C display
>   *-display                 
>        description: VGA compatible controller
>        product: HD Graphics 5500
>        vendor: Intel Corporation
>        physical id: 2
>        bus info: pci@0000:00:02.0
>        version: 09
>        width: 64 bits
>        clock: 33MHz
>        capabilities: msi pm vga_controller bus_master cap_list rom
>        configuration: driver=i915 latency=0
>        resources: irq:48 memory:c0000000-c0ffffff memory:b0000000-bfffffff ioport:5000(size=64) memory:c0000-dffff


Zrobiłem jeszcze jedne test. Porównałem procesor AMD Phenom II (6 rdzeni) z
kartą GTX 1650. GTZ 1650 działa 260 razy szybciej. Ani karta, ani procesor
nie były podkręcane. Jako ciekawostkę dodam, że karta pobiera (według
producenta) 75W mocy, a procesor nawet 200. Wniosek z tego taki, że jeśli
jakieś obliczenia w ogóle można przeprowadzić na GPU, to przyspieszenie
może być kolosalne. Jeśli podłączymy 8 takich kart do płyty głównej to
mamy przyspieszenie 2080 razy. 

Jakby użyć jakiś wbudowanych funkcji z OpenCL do przetwarzania grafiki, to
przyspieszenie byłoby pewnie jeszcze większe - ciekawe jakie, ma ktoś takie
doświadczenia?

I kolejna sprawa, jeśli na procesorze (GPU) przeznaczonym do ogólnych obliczeń
można uzyskać przyspieszenie 260 razy, to jakiego przyspieszenia 
można się spodziewać na układach FPGA i ASIC?

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#33812

W dniu niedziela, 22 marca 2020 20:34:26 UTC+1 użytkownik M.M. napisał:
> 
> Zrobiłem jeszcze jedne test. Porównałem procesor AMD Phenom II (6 rdzeni) z
> kartą GTX 1650. GTZ 1650 działa 260 razy szybciej. Ani karta, ani procesor
> nie były podkręcane. Jako ciekawostkę dodam, że karta pobiera (według
> producenta) 75W mocy, a procesor nawet 200. Wniosek z tego taki, że jeśli
> jakieś obliczenia w ogóle można przeprowadzić na GPU, to przyspieszenie
> może być kolosalne. Jeśli podłączymy 8 takich kart do płyty głównej to
> mamy przyspieszenie 2080 razy. 
> 

wydaje mi sie ze sa to pochopne wnioski
dlatego ze problem jest raczej w tym ze to zacznie zwalniac gdy te rownolegle kanaly okaża sie jednak czesciowo zalezne
miedzy sobą.. te 260 to zgaduje wzgledem jednego rdzenia?

ja jak mowie spoedziewalbym sie przyspieszenia kilka razy (wzgledem calego procka) w pesymistycznym, moze
kilkanascie w srednim/dobrym i kilkadziesiat to raczej w jakims mage dobrym (na jakiejs b mocnej karcie)

taie sa moje wrazenie po testach i tym co czytelem w necie pare lat temu, mozliwe ze od tego czasu w sumie te karty sa juz mocniejsze, bo w sumie powinny byc bo karty chyba powinan rosnac szybciej w mocy niz procki

moze kolega porobic wiecej testow i potestowac.. ja nie mam zbytniego pomyslu
co moglbym sam konkretnie popisac na opencl choc poczytac cs w necie moze i moglbym, niestety przegrywam ostatnio walke z motywacja do kodowania na cale duze obszary czasowe (i generalnie nie 
robie nic poza strasznie slamazarnym 
humanistycznym raczej mysleniem wypelnionym stresem i zmartwieniami..takie zycie niestetym bue na dibrego czasu na kodowanie)


> Jakby użyć jakiś wbudowanych funkcji z OpenCL do przetwarzania grafiki, to
> przyspieszenie byłoby pewnie jeszcze większe - ciekawe jakie, ma ktoś takie
> doświadczenia?
> 
> I kolejna sprawa, jeśli na procesorze (GPU) przeznaczonym do ogólnych obliczeń
> można uzyskać przyspieszenie 260 razy, to jakiego przyspieszenia 
> można się spodziewać na układach FPGA i ASIC?
> 
> Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#33813

On Monday, March 23, 2020 at 12:53:16 AM UTC+1, fir wrote:
> W dniu niedziela, 22 marca 2020 20:34:26 UTC+1 użytkownik M.M. napisał:
> > 
> > Zrobiłem jeszcze jedne test. Porównałem procesor AMD Phenom II (6 rdzeni) z
> > kartą GTX 1650. GTZ 1650 działa 260 razy szybciej. Ani karta, ani procesor
> > nie były podkręcane. Jako ciekawostkę dodam, że karta pobiera (według
> > producenta) 75W mocy, a procesor nawet 200. Wniosek z tego taki, że jeśli
> > jakieś obliczenia w ogóle można przeprowadzić na GPU, to przyspieszenie
> > może być kolosalne. Jeśli podłączymy 8 takich kart do płyty głównej to
> > mamy przyspieszenie 2080 razy. 
> > 
> 
> wydaje mi sie ze sa to pochopne wnioski

Na pewno test jest skrajnie uproszczony. Ale tak prosty test ma swoje
zalety, mianowicie znacznie lepiej rozumiem prosty test niż skomplikowany.
Poza tym może testy rozbuduję... Na razie każdy kernel pracuje tylko na
swoich 4 bajtach danych, jest to sytuacja idealna dla GPU, ale dla CPU też, bo
CPU może te 4 bajty ciągle mielić w rejestrze.


> dlatego ze problem jest raczej w tym ze to zacznie zwalniac gdy te 
> rownolegle kanaly okaża sie jednak czesciowo zalezne
> miedzy sobą.. 

Tak, ale w CPU występuje ten sam problem. Gdy mam w N wątkach na 
procesorze N rdzeniowym często dostęp do 'losowych' obszarów RAM, to
program w N wątkach działa z podobną szybkością jak w jednym wątku - to
nie pomyłka, naprawdę 6 wątków w takim programie (bez rozległych sekcji
krytycznych) działa z podobną szybkością jak 1 wątek.


> te 260 to zgaduje wzgledem jednego rdzenia?

Właśnie nie, względem jednego rdzenia było chyba 1550 :D 
258 razy względem 6 rdzeni :D

 
> ja jak mowie spoedziewalbym sie przyspieszenia kilka razy (wzgledem calego 
> procka) w pesymistycznym, moze kilkanascie w srednim/dobrym i kilkadziesiat
> to raczej w jakims mage dobrym (na jakiejs b mocnej karcie)

Ja miałem różne informacje, postanowiłem sam sprawdzić.


> taie sa moje wrazenie po testach i tym co czytelem w necie pare lat temu,
> mozliwe ze od tego czasu w sumie te karty sa juz mocniejsze, bo w sumie 
> powinny byc bo karty chyba powinan rosnac szybciej w mocy niz procki

A no tak, ale karta GTX 1650 (która wypada 260 razy szybciej niż phenom II) 
też nie jest zbyt mocna, w rankingu ma 3516 punktów. Jej zaletą jest to, że
jest tania i mało prądu pobiera. W poniższym rankingu najlepsze karty mają
trzy razy więcej punktów:

https://www.videocardbenchmark.net/directCompute.html


> moze kolega porobic wiecej testow i potestowac.. 

Tylko jakie tu by testy zakodować żeby się nie przepracować... Może problem
komiwojażera jakimś prostym algorytmem... 


> ja nie mam zbytniego 
> pomyslu co moglbym sam konkretnie popisac na opencl choc poczytac cs w 
> necie moze i moglbym, 

Mnie ciekawi skalowanie obrazka 2D, bo są gotowe funkcje i typy do tego celu:
https://github.com/oddbjornkvalsund/opencl-img/blob/master/src/main/resources/resize.cl



> niestety przegrywam ostatnio walke z motywacja do
> kodowania na cale duze obszary czasowe (i generalnie nie robie nic poza
> strasznie slamazarnym 
> humanistycznym raczej mysleniem wypelnionym stresem i zmartwieniami..takie 
> zycie niestetym bue na dibrego czasu na kodowanie)

Lipa panie.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#33821

On 22/03/2020 20:34, M.M. wrote:
> producenta) 75W mocy, a procesor nawet 200. Wniosek z tego taki, że jeśli
> jakieś obliczenia w ogóle można przeprowadzić na GPU, to przyspieszenie
> może być kolosalne.

Ale tylko jeśli alorytm dzieli się na rdzenie i nie komunikuje się 
pomiędzy. Nie każdy da się łatwo podzielić. Spróbuj też korzystać z 
pamięci karty, przyśpieszenie nie będzie aż takie imponujące. Sprawdź 
też jakie masz transfery CPU z i do pamięci karty, ogólnie wyjmowanie 
czegoś z karty jest bolesne.

> I kolejna sprawa, jeśli na procesorze (GPU) przeznaczonym do ogólnych obliczeń
> można uzyskać przyspieszenie 260 razy, to jakiego przyspieszenia
> można się spodziewać na układach FPGA i ASIC?

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ć.

OpenCL stara się co prawda to FPGA chować za abstrakcją, ale układy 
programowalne nie współpracują dobrzez z językami imperatywnymi, dlatego 
isnieje do ich programowania zupełnie inny zbiór języków z innymi 
pojęciami. No i karty FPGA w zasosowaniach programowania OpenCL to 
ciągle ciekawostka, bardzo droga.

[toc] | [prev] | [next] | [standalone]

#33822

On Tuesday, March 24, 2020 at 6:58:47 PM UTC+1, heby wrote:
> On 22/03/2020 20:34, M.M. wrote:
> > producenta) 75W mocy, a procesor nawet 200. Wniosek z tego taki, że jeśli
> > jakieś obliczenia w ogóle można przeprowadzić na GPU, to przyspieszenie
> > może być kolosalne.
> 
> Ale tylko jeśli alorytm dzieli się na rdzenie i nie komunikuje się 
> pomiędzy. Nie każdy da się łatwo podzielić. Spróbuj też korzystać z 
> pamięci karty, przyśpieszenie nie będzie aż takie imponujące. Sprawdź 
> też jakie masz transfery CPU z i do pamięci karty, ogólnie wyjmowanie 
> czegoś z karty jest bolesne.

Generalnie mam podobny pogląd na ten temat co Ty.  Piszesz o
korzystaniu z pamięci karty, rozumiem, że masz na myśli sytuację, w
której N wątków pracuje na karcie i N odczytuje (zapisuje) jakieś 
dane z tej karty. Myślę, że jeśli każdy wątek będzie miał dostęp do 
pamięci karty w sposób w miarę sekwencyjny to do spowolnienia nie 
dojdzie - ale pewności nie mam. Szykuję się do napisania kilku 
kolejnyhch mikro programików do dalszych testów. Gdzieś czytałem że
proste algorytmy do problemu komiwojażera przyspieszają na 
GPU do 300 razy (względem wszystkich rdzeni jednego CPU w podobnej
klasie cenowej), a wątki mają wspólną pamięć (rozmiaru N^2) do 
odczytu i każdy ma mały (rozmiaru N) obszar do zapisu i odczytu.
Chyba to zakoduję do testów, podzielę się wynikami.

Częste transfery pomiędzy pamięci karty a pamięcią komputera na
pewno spowolnią obliczenia. 

By się przydało gdzieś zebrać kompletny(!) zetaw warunków koniecznych, 
przyspieszenie było możliwe. Słyszałem że jest kilka pułapek, nie wiem o
jakie pułapki chodzi. Na razie do głowy przychodzą mi takie warunki:
1) Zadanie musi być paralelizowalne algorytmicznie, mało sekcji
   krytycznych, mało synchronizachi.
2) Stosunek transferów RAM<->GPU do obliczeń musi być mały.
3) Stosunek obliczeń do odczytów sekwencyjnych (w pamięci karty) musi 
   być...  no właśnie, nie wiem jaki musi być.
4) Stosunek obliczeń do zapisów sekwencyjnych (w pamięci karty) musi 
   być... też nie wiem jaki.
5) Stosunek obliczeń do odczytów/zapisów NIE-sekwencyjnych musi
   być... chyba bardzo mały, ale pewności nie mam, może niektóre 
   GPU radzą sobie z czymś takim?
6) Gdy są obliczenia na grafice to przyspieszenie jest jeszcze
   większe, bo karty mają funkcje wbudowane do grafiki.

Czy coś mniej lub bardziej ważnego zapomniałem?


> 
> > I kolejna sprawa, jeśli na procesorze (GPU) przeznaczonym do ogólnych obliczeń
> > można uzyskać przyspieszenie 260 razy, to jakiego przyspieszenia
> > można się spodziewać na układach FPGA i ASIC?
> 
> 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];
}
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.

 
> OpenCL stara się co prawda to FPGA chować za abstrakcją, ale układy 
> programowalne nie współpracują dobrzez z językami imperatywnymi, 

Właśnie tego się obawiałem :/


> dlatego 
> isnieje do ich programowania zupełnie inny zbiór języków z innymi 
> pojęciami. No i karty FPGA w zasosowaniach programowania OpenCL to 
> ciągle ciekawostka, bardzo droga.

Po wygooglaniu faktycznie znalazłem jakieś karty za 40-50tys PLN :/


Pozdrawiam 

[toc] | [prev] | [next] | [standalone]

#33823

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.

[toc] | [prev] | [next] | [standalone]

#33824

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

[toc] | [prev] | [next] | [standalone]

#33825

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

[toc] | [prev] | [next] | [standalone]

#33826

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

[toc] | [prev] | [next] | [standalone]

#33827

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?)

[toc] | [prev] | [next] | [standalone]

#33828

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

[toc] | [prev] | [next] | [standalone]

#33829

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?

[toc] | [prev] | [next] | [standalone]

#33830

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

Co to?

[toc] | [prev] | [next] | [standalone]

#33831

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

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web