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/

do góry

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

do góry

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

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

Co do SSE, to nie wpadłem na pomysł taki, żeby
robić wersję bez SSE, więc nie mam porównania.

Pozdrawiam
Edek

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał:

> Właśnie wynadujesz kwadratowe koło. Aplikacja *nie* powinna nic o pamięci wiedziec
poza tym że
> może jej użyć.

Bardzo mądre słowa. Wręcz sedno !

Pozdrawiam

AK

do góry

On 14/04/2012 12:36, Sebastian Biały wrote:
> On 2012-04-14 02:54, Andrzej Jarzabek wrote:
>> Ale:
>> * Alokacja na stosie
>
> To nie język funkcyjny żeby było to wygodne. Zdecydowana większość kodu
> pisanego w C++ i Javie działa intensywnie używając heapu.

W Javie zdecydowanie, bo nie da się utworzyć obiektów na stosie.

W C++ nie podejmuję się powiedzieć jak jest z większością, ale na pewno
alokację na stosie wykorzystuje się intensywnie w krytycznych z punktu
widzenia wydajności fragmentach programu. Funkcyjność nie ma nic do
rzeczy, "ciasna pętla" często potrafi nawet w C++ polegać na tym, że się
jakąś wartość skądś uzyskuje (jest zwracana przez funkcję), umieszcza w
zmiennej lokalnej, i przekazuje jako argument do kolejnej funkcji, która
ci zwraca coś, co jest np. dodawane do akumulatora zliczającego sumę w
tej pętli. Wszystko to może się odbywać na stosie (w zależności od
charakteru danych, ale często tak)

>> * Kompozycja
>
> Stoi w sprzeczności z separacją funkcjonalności.

Boponieważ?

> Wyważenie jest cieżkie.
> Wprowadzanie w design od razu optymalizacji na pamięć jest niebezpieczne.

Kompozycja jest w C++ najbardziej naturalna, to inne relacje (przez
wskaźniki czy inne smart pointery) musisz "wprowadzać" ze względu na
cośtam (shared ownership, polimorfizm itd.)

>> * Zamiast zwykłej sterty można stosować poole czy regiony.
>
> Poole czy regiony problem tylko zamieniają na mniejszy, lokalny. Ale
> bedzie dalej występował.

Jeśli dobrze przemyślisz użycie tego, to w praktyce nie będzie.

> Nie piszę o Javie. Chodzi ogólnie o to że C++ nie wymyslił niczego
> najlepszego w dziedzinie zarządzania pamięcią.

Ja pisałem o Javie. A kto wymyślił coś najlepszego w tej dziedzinie?

do góry

Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:

> Ja pisałem o Javie. A kto wymyślił coś najlepszego w tej dziedzinie?

Np. Simula

AK

do góry