W dniu niedziela, 20 sierpnia 2017 12:30:14 UTC+2 użytkownik M.M. napisał:
> On Sunday, August 20, 2017 at 10:14:33 AM UTC+2, fir wrote:
> > odnosnie optymalizacji to moge jeszcze dodac cos bo widzialm gdzies
> > tu jak zwykle te niemal bezdennie glupie klasyczne pseudodyskusje
> > czy programista zoptymalizuje kod lepiej niz kompilator itd itd
> Dlaczego uważasz te rozmowy za głupie?
>
>

dlatego ze ktos kto tak dyskutuje kompletnie nie rozumie problemu

>
> > z tego jak ja to widze psrawa wyglada tak ze programista zoptymalizuje
> > kod lepiej problem jest jednak w czym innym - dzis - z tego jak to
> > mi sie jawi - kody sa memory-bound to nie asembler spowalnia kody
> > tylko memory-bandwidth, innymi slowy problem jest w tym ze nawet
> > 100-krotne zoptymalizowanie arytmetyki moze spowodowac na przyklad
> > powiedzmy jedynie 1% przyspieszenia -
> Generalnie masz rację. Ile razy przyspieszy 100-krotne zoptymalizowanie
> arytmetyki? To zależy od programu. Ja myślę, że przyspieszyłoby
> powiedzmy od 2 do 100 razy.
>

raczej przyspieszy od 0 do 10 %
wlasnie dlatego ze kod juz na starcie jest memory bound (dzis chyba trudna napisac az
taki krap ktory bylby az tak bardzo cpu bound bys mogl go przyspieszyc 5 razy co tu
mowic o 100x)

kazdy kod ma swoja naturalna predkosc ktora rowna sie memory bandwidth i powiedzmy ze
jest to 1 ms na 1 MB na rdzen (tak naprawde jest to troche wiecej, na kompach ktore
testowalem bylo to do 10 razy wiecej, ale dla utrzymania uwagi mozna przyjac 1 ms na
1 MB)

poprawne napisany kod wstepnie zoptymalizowany w c bedzie bliski tego

jelsi ta nieprzekraczalna granice uznasz za 100% to arytmatyka moze dodac nie wiem
powiedzmy dodatkowe 30%
i chocbys nie wiem co robic przepisywaniem asma zredukujesz tylko te 30% a 100%
nieprzekraczalnej granicy nie ruszysz innymi slowy max co przyspieszysz nawet
najlepszym recznym samem to 30% - i to nie dlatego dzis nie pisze sie za duzo w asmie
ze kompilatory generuja tako dobry asm tylko wlasnie dlatego ze chocby najlepszy asm
nie da za duzo

(chyba ze kod jest totalnym crapem i nie jest memory bound ale takie kody
rzadko sie widzi sa naprawde malo prawdopodobne)

wiecej chyba nie che mi sie o tym gadac bo albo to rozumiesz albo nie (a ja
powtarzajac w kolko to samo tylko tracilbym swoj czas czego wolalbym uniknac)

(ps mozliwe ze kody ktore sa memory bound mozna dalej zoptymalizowac ale
to raczej jakimis algorytmami w c
ktore beda oszczedzac operacje na pamieci a nie przepisywaniem na asma,
(mozliwe tez ze pewne szczegoly mi unikaja ale ogolna wizja memory-bound raczej jest
prawdziwa)

samo to przepisywanie kodow by unikaly przetwazania pamieci jest raczej co nieco
nieprzyjemna i 'nadbudowana' optymalizacyjna algorytmiką i moim zdaniem niekoniecznie
to trzeba robic bo kody robia sie od tego dluzsze i brzydsze a nie maja dodatkowej
funkcjonalnosci wrecz nabieraja węższej ak ze jest to mocno specjalistyczna dzialka)






> > Zupelnie inaczej bylo kiedys kiedy to memory bound nie bylo
> > widoczne i wszystki liczylo sie predkoscią poszcegolnych instrukcji,
> > w danej sytuacji przyspieszenie asemblera 100 razy dawalo przyspeszenie
> > 100 razy... dzisiaj (jeli wywalic takie funkcja jak sin sqrt pow exp div)
> > kody sa glownie memory bound i dlatego przepisywania asma po prostu
> > niewiele daje -
> Można skrócić czas wykonania od np. 7% do 50%, zależy od przypadku.
>
>
> > jak robic optymalizacje tego memory bound?
> Ja np. zaimplementowałem tak drzewa czerwono-czarne, żeby wszystkie
> dane i meta-dane były w ciągłym obszarze pamięci. Można jeszcze
> spróbować tak, aby dane i meta dane trzymać w dwóch osobnych
> tablicach - ale ta technika w niektórych przypadkach zaszkodzi.
> Wracając, w wyszukiwaniu w drzewie ciągle jest skok pod
> (prawdopodobnie) losowy adres. W wyszukiwaniu binarnym w tablicy
> skok pod losowy adres jest tylko na początku:
> while( max - min > L ) {
> middle = (max - min)/2;
> [...]
> }
> while( min < max ) {
> [...]
> min ++ ;
> }
>
>
> > nie zajmowalem sie tym za duzo ale zdaje sie ze na przyklad unikanie
> > malych zmiennych posrednich niewiele przyspiesza (na szczescie - bo
> > rownoczesnie to zanczy ze mozna ich uywac tj uzywani ich niewiele
> > spowalnia) .. przepisywanie arytmetyki
> > jak wspomnialem w sumie sporo daje (mam tu na mysli przepisywanie i >
> > upraszcanie raczej na poziomie c a nie asma)
> Tak, na jedno wychodzi.
>
> > ale i tak sprawa rozbija sie o memory bound (memory bound jest dzisiaj
> > sciana i jesli mozesz zoptymalizowac asma to tylko DO tej sciany a nie
> > poza nia - dlatego przepisywanie w asmie nie daje tak jak kiedys
> > przyspieszen rzedu 10x 30x i
> Hmmm mi kiedyś dawało zazwyczaj 3x. Myślę, że przyczyną jednak było to, że
> kompilatory kiedyś były kiepskie.
>
>
> > dlateo wlasnie nie jest tak wazne jak kiedys) samego memory bound nie
> > wiem jak przyspieszyc byc moze sie nie da - podstawowe moemory bound
> > liczy sie po prostu wielkoscią inputu i wielkoscia outputu (w megabajtach)
> > t co ew mogloby to przyspieszyc to jakies skomplikowane algorytmy
> > selekcjonujace input i output
> Generalnie się zgadzam z Tobą, ale nie aż tak dosłownie. Przepisanie asma
> trochę też daje. Tyle że dziś kompilatory dobrze to robią.
>
>
> > -- ale to jest skomplikowane i zaciemnia algorytmy
> > tak ze ja osobiscie o to zbytnie nie dbam
> > jak zwykle na koniec warto wspomniec
> > zapewne opencl bo GPU maja mamory bandwidth np 10 razy wiekszy niz
> > procki tak ze jak ktos chce robic potezny flow przetwazania to
> > pewnie powinien si etego nauczyc ;c
> Na xeonphi jest fajnie, po prostu daje się
> #pragma omp parallel
> Niczego nie trzeba się uczyć i bangla. Ale na pewno podejście od bebechów
> przyspieszyłoby dużo więcej.
>
>
>
> > (ogolnie to napisalem wyzej to co wiem na ten temat, sam ostatnio
> > jednak zaczalem jak wspomnielem mniej interesowac sie optymalizacją -
> > choc ciagle interesuje mnie rev-engeenereeng /disasembling, vide
> > pisanie asemblera x86)
>
> Od kiedy znalazłem fragment kodu napisany przez kosmitów, też interesuję
> się wsteczną inżynierią ;-)
>
> Pozdrawiam