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?



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

> 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