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.