Edek Pienkowski <e...@g...com> napisał(a):

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

Czyli podsumowując napracowałeś się bardzo dużo nad implementacją, a
efektów zbyt dużo nie było. Tak to już chyba jest... ale bardzo zdumiewa
mnie fakt, że używając SEE / CUDA nie uzyskałeś na czymś takim jak
sztuczne sieci neuronowe kolosalnego przyspieszenia. Gdzieś czytałem
że na jednej tesli (która zdaje się ma 4 GPU) uzyskano przyspieszenie
260 razy względem dwu- (albo nawet cztero-) procesorowego Xeona.

Nie wiem jak to dokładnie implementowałeś... w swojej implementacji
czegoś podobnego właśnie nie widzę sensownego miejsca na optymalizację.
Ja mam po prostu zbiór neuronów, a wejścia niczym się nie różnią od
neuronów. W uproszczeniu neuron to u mnie jedna liczba zmiennoprzecinkowa.
Potem ma tablicę mniej/więcej takich struktur:
struct Connect {
int input;
int output
float weight;
};

Serce i zarazem gorący punkt algorytmu to taka pętla:

float neurony[1..ilosc_neuronow];
neurony[1..ilosc_wejsc] = wektor_wyjsciowy;
for( i=0 ; i<connects.size ; i++ ) {
neurony[ connects[i].output ] += funkcja_nieliniowa( neurony[
connects[i].input ] );
neurony[ neurony[ connects[i].input ] = funkcja_zaniku( neurony[
connects[i].input );
}
return neurony[ilosc_neuronow-ilosc_wyjsc..ilosc_neuronow];

Co tu da się zoptymalizować to nie wiem :)
Ale na Tesli, do póki dane mieszczą się w jej pamięci, to powinno działać
równolegle na 512 procesorach...

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/