Dnia Sun, 15 Apr 2012 02:54:39 +0000, M.M. napisal:

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

Pisząc o % pisałem o CPU. Jeżeli chodzi o CUDA, to jabłka do gruszek,
zależy od karty. Pisząc o 1.3 miałem na myśli GeForce 8 - nie ma
o rząd wielkości lepszej przepustowości niż L2 CPU, było szybciej
jeżeli uruchomiło się 20 sieci zamiast jednej; przepisywałem to
później tak, żeby równolegle nie było 20 sieci tylko 20 przebiegów
jednej sieci; dla małych sieci ciężko było mieć 20 blocków
działających na jednym przebiegu jednej sieci.

Te o o których piszesz mogły mieć bardziej regularną strukturę,
dla kart GPU struktura dostępów do RAM ma kolosalne znaczenie.
O ile funkcje nie są b. skomplikowane, limitem jest RAM,
nie GFLOPS. Dlatego brałem część źródła do shared i z shared było
szybciej. Tyle, że już wtedy musiałem mieć albo testy albo
osobną kartę, bo debugger nie działa jak na niej siedzi desktop.

Sieć każdy-z-każdym można przyśpieszyć trywialnie.

Na CPU te kilka % w algorytmie, którego zasady zmienić się nie
da, to też coś.

>
> 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 :)

- Structure of Arrays vs. Array of Structures
- iterując po neuronach a nie po linkach (po linkach wewnętrzna pętla)
można mieć linki w tablicy, offsety tylko źródła w tablicy, a iterować
po docelowych neuronach (to pull, można analogicznie push)
- albo mieć nie offsety tylko pointery
- ponieważ nie ma pętli layerów, można wrzucić neurony wszystkich layerów
do jednej tablicy i jednej pętli
- i podobne, kolejność iteracji taka, żeby mieć najlepsze locality

Tą część CPU to można przepisać w dowolnych kombinacjach w kilka
godzin tak naprawdę, przy CUDA jest więcej zabawy z rozmieszczeniem
tego odpowiednio w pamięci.

> Ale na Tesli, do póki dane mieszczą się w jej pamięci, to powinno działać
> równolegle na 512 procesorach...

Nie mam Tesli... to czysto amatorska zabawa. Nie pamiętam liczb,
ale było szybciej nie o %, tylko wielokrotnie - przy czym co innego
8xxx, a co innego 4xx czy 5xx. To tak jakbyś porównywał p4 do i7.

Edek