Dnia Sat, 14 Apr 2012 11:26:18 +0000, M.M. napisal:

> Edek Pienkowski <e...@g...com> napisał(a):
>
>> Ja miałem. Bawiłem się jedym algorytmem przez miesiąc, przepisując
>> często całość inaczej. Najgorsze było to, że czasami efekty były
>> odwrotne na Core2 niż na i7.
> Rozumiem że chodzi o zmiany implementacyjne, a algorytm ciągle był
> ten sam. Można wiedzieć jakie miałeś przyspieszenia pomiędzy "rozsądną"
> implementacją a tą najlepszą i co to za algorytm?

Sieć NN, nuda jak cholera. Każdy pseudo-neuron był połączony z
poprzednim(i) layerem(ami) na zasadzie kształtu - layer 2D,
kształt tego rodzaju, że obejmuje neurony "najbliżej", z tymi ma link,
chociaż mógł być "co któryś", jak w iteracji ze step.

Optymalizowałem uczenie, czyli forward pass, ocena, uczenie. Uczenie
na zasadzie zmian przy złym wyniku bez back-prop., potem jeszcze
wzmacnianie połączeń przy "dobrym". Funkcja typu clip (0.,1.),
ale binaryzowana 3-8 bitów na neuron
(przy 3: 0., 0. + 1./7. , ..., 1.). Pomijając gęstość
informacji na podstawie czytanych prac, słabo znam temat NN,
to binaryzowanie fajnie na CUDA działało, bo dużo więcej
się mieściło w shared, chociaż na starych kartach (1.3) to było
jeszcze przewidywalne, ale na cc 2.1 już nie miałem czasami pojęcia,
dlaczego coś jest szybsze lub, oczywiście z zaskoczenia, 30%
wolniejsze.

Jakkolwiek by się nie napisało algorytmu dostępy bywały mocno
nieregularne, to nie każdy-z-każdym. Na i7 lepszy był naiwny
algorytm, każdy link miał dwa floaty i kilka pointerów, alokowany
przez new, a na Core 2 lepsze było SoA, chociaż tu znowu
sporo zależało od "kształtu", ile linków na neuron i proporcji
do rozmiaru layera. Przy wielkich oczywiście pomagało tiling
ze względu na cache, ale ja zazwyczaj miałem dużo layerów
raczej niewielkich (nieliniowe mają inne
właściwości, jest sens robić więcej layerów, ilość informacji
w nieliniowych jest inna niż w liniowych, o ile znam temat;
w każdym razie to nie jest minimalizacja).

Tylko dlatego tak naprawdę sporo czasu na to poświęciłem,
że właśnie nie było to nic regularnego, a jednocześnie w miarę
niewielkie.

Różnice były rzędu kilku %, ale zdarzały się odchyły rzędu
20% gorzej. Całość po kompilacji trafiała do jednej wielkiej
metody, zmieniałem głównie layout danych, kolejność iteracji,
alignment, opcje typu fp+sse/sse z różnym skutkiem no i
to PGO. Oczywiście główną alternatywą był push albo pull,
swoje też dodawał random.

Coś czego do dzisiaj nie rozumiem: pierwsze przebiegi były
sporo wolniejsze, potem kilka ze 2-3% szybsze, potem plateau o ile
system czegoś akurat nie robił. Chyba na i7, nie pamiętam. Tego
że seria przebiegów miała ten peak nie rozumiem,
a sprawdziłem, że mi się wcale nie przywidziało, kilka razy.

Edek