🚀 go-pugleaf

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