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