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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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.htm
l


> 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

do góry

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.

do góry

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

do góry

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.

do góry