W dniu wtorek, 20 listopada 2018 10:46:04 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 19 listopada 2018 23:12:21 UTC+1 użytkownik
g...@g...com napisał:
> > Jak będziecie używać mojej funkcji memmove, to może nawet zadziała
> > o ćwierć promila szybciej na niektórych procesorach.
>
> takie teksty nie brzmia za madrze (pominawszy fakt ze tego typu spory/dyskusje
(tego okreslonego typu) wogole nie sa za madre) (z trzeciej stony wlaczanie sie w
takie logiczne podejscie
> (typu wypowiadanie zdan i rozrtrzasanie co jest rpawda a co nie) jest ok)
>
> ile to jest cwierc promila? 0.025 %,
> cos tu nie gra, wygladami na to ze
> ktos kto to pisze ma bardzo osobliwe podejscie do optymalizacji i robil to albo
jakos dziwnie albo zupelnie zle
> albo wogole
>
> ja optymalizowalem relatywnie sporo i
>
> 1)
> takie wartosci jak 0.025% nie wchodza
> tam wogole w gre bo te czasy wogole nie sa tak stabilne by moc to zauwazyc i
zmierzyc (aq czas czystego memcopy to juz wogole gdy ja to mierzylem niezle
oscylowal)
> 2)
> samego memcopy raczej sie nie optymalizuje bo przestrzen by tu poprawic jest mala
ale juz cale okolice bliskie
> memcopy - jak najbardziej
> 3) czynniki jakimi mozesz przyoptymalizowac juz calkiem dobrze ale zwyczajnie
napisany kod w c czy tam c++ moga byc naprawde spore, i wtedy nie wyrazasz tez tego
raczej w procentach tylko w 'x' ile razy, to ilemozesz osiagnac zalezy od natury
zagadnienia i od tego jak wstepnie przyoptymalizowany byl kod oraz od tego jak bardzo
daleko chesz isc w ta optymalizacje
>
> ale moje przykladowe casy jakie ja znam
>
> 1) kiepsko napisany kod 60 ms na ramke
> 2) pobawianie sie z flagami kompilacji
> (ale takie ktore polega na tym ze po roznych zmianach patrzysz na wplyw a nie tylko
na pale wlaczysz kilka) oraz wogole
> wyodrebnienie petli i przepisanie jaj tak by bylo jasne co tam sie dzieje (jelsi
ktos napisal bez wiekszej uwagi) 30 ms na ramke
>
> (dla mnie to pow punkt startoway bo jzu na starcie zwracam na to uwage)
>
> 3) poprzepisywanie, porozwijanie wyrazen, zredukowanie dzielen, poprzepisywanie na
inline (choc to malo pomaga raczej chodzi o to by miec wglad co tam sie dzieje),
ogolne poupraszczanie tak ze kod bardziej jest przyjazny podejsciu optymalizacyjnemu
- 16 ms
>
> 4) tabelaryzowanie kawalkow kodu, porozbijanie kodu na specjalne casy pod wzgledem
optymalizacji, dorobienie skomplikowanych algorytmow 'odrzucania roboty', zagladanie
do generowanego asma, ew wwalenie paru intrinsincow sse... przerobienie niektorych
czesci na kod ktory dzial w sposob lekko przyblizony (zlinearyzowany) (strata jakosc
wzgl szybkosci) - 1.6- 1.2 ms
>
> 5) zejscie na poziom asma i robienie jakiegos hardkoru w mikrokodzie razem ew
jeszcze z dorobieniem jeszcze wiekszych rewolucji w algorytmach odrzucania -
prawdopodobnie jeszcze mozna przyspieszyc 2 razy (i zejsc ponizej milisekundy ale to
juz hardkor i tego nie robie za duzo roboty i nei znam az takl asma
>
>
> slowem jak ktos mowi ze optymalizacja to walka o promile to raczej nie wie co mowi,
wg mopich doswiadczen optymalizacja to raczej 'srednio' czynnik 10x 15x jeslis ie
nawet zaczyna z calkiem poprawnego kodu w c
>
> nie widze przypadku w ktorych mowienie o promilach mialoby sens - bo to chyab
musialobybyc w wypadku potwznie przyoptymalizowanego kodu a taki kod ma juz wtedy
procentowo spoore fluktuacje wiec gadanie o promilach nie ma sensu

moze jeszcze 3 drobne uwagi co do tego powyzej:
1) calkiem mozliwe ze optymalizacje roznych programow sa zasadniczo rozne
i generuja rozne wnioski - i by moc duzo
o tym powiedziec tzrebby rozne przypadki optymalizowac (sam mam na mysli glownie
optymalizacje grafiki perpixel (glownie 3d) na cpu) choc nie tylko costam jeszcze
czasem tez sie troche optymalizowalo ale slabiej pamietam

2) ten pierwszy krok ktory wymienilem jest troche nienormalny i nie dotyczy tak
bardzo tego co ja pisze (bo dotyczy on glownie prostych bledow) ale podejrzewam moze
dotyczyc kodow wielu ludzi bo wydaje mi sie ze wiele ludzi nie mierzy na bierzaco
czasow wykonania - nie sa swiadomi zmian tych czasow, ich wartosci itd... mz to moze
powodowac toz e kod ma pewne bledy - np jesli nei mierza czasow moga byc nieswiadomi
jakie obciazenia pododuje systemowe api (ostatniuo pisalem swoj wlasny edytor tekstu
w winapi i okazuje sie np ze rysowanie fontow winapowskin TextOutem czasem dziala
szybko a czasem dziwnie wolno (np o ile pamietam rysowanie malych fontow po literce
dzia dziwnie wolno itp)-- niesprawdzanie tego to nawet nie blad optymalizacji tylko
raczej zwykly blad programu

[wogole z rysiowaniem tych fontow ogolnie mam pewien problem i nawet chetnie bym tu
napisal na czym to polega, ale raczej nikt tu i tak nie znalby na to odpowiedzi
- w skrocie mowiac nie wiem jak zrobic to by moc swobodnie przeplatac rysowanie
fontow z rysowaniem np spritow moimi procedurami per piksel ->

ogolnei by cos narysowac rysuje tow ramie po czym blituje do contekstu i dopiero
wtedy mge na tym kontekscie narysiowac fonty TextOutem z gdi

gdybym chcial to przeplatac to by cos narysowac na tym wszystkim musialbym sciagnac
to z kontekstu do ramu naryswoac do ramu i znowu blitnac - innymi slowy takie
swobodne przeplatanie powoduje mase blitow i sciagniec wiec jest spieprzone

do tego nie pamietam czy przypadkiem tych textoutow nie moge wywoalywac tylko z
handlera spod WM_PAINT (juz nie pamietam bo robilem to pol roku temu) a ja chcialbym
to rysowanie miec zupelnie wolnym, przeplatac i wywolywac dowolnie z kodu ramki (idle
loop)

naplsz("ala ma kota");
draw_line(10,10,300,400,0xffffff);
naplsz("zzzz");
draw_sprite(...)

a nie byc sztucznie ograniczanym, przez api (gdzie pisania napisow mozesz tylko
zrobic po calej grafice jakby w odzielnej czasowo "warstiw" i nie mozesz tego uzywac
normalnie - jak printfa) --- nie jestem pewien czy w wianpi sie da to zrobic (nie
wiem bo nei czytalem o tym wszystkego co sie da wyszukac w necie
bo wtedy te problemy mnie zmeczyly a czcialem kodowac sam edytor

nie dotyczy to strikte optymalizacji tylko raczj poprawnego kodowania w realacji do
wydajnosci ale jest mz ciekawym przykladem ]

przez toz e ludzi ne bierzaco nuie sprawdzaj tej wydajnosci moim zdaniem
kod mozne poprawic wydajnosciowo czesto nawet nie piszac optymalizacji, tylko raczej
bedac swiadomym co jak wydajnie dziala i mierzac czasy

pozaym warto poswprawdzac te flagi optymalizacji, co smieszne okazuje sie ze
zmiana gcc z jednaj wersji na inna (przy tych samych opcjach) moze spowodowac to ze
zmiania sie szybkosc wygenerowanego kodu (u mnie raz np kod zwolniel o jakies 10 czy
20% przy przejsciu kiedys z chyba gcc 4.9 na 5.2 czy cos takiego), przy bawieniu sie
opcjami tez np warto zwracac pewnie uwage czy kompilator nie generuje jakichs
niespodzianek bo kompilatory schodza na psy troche, wrzucaja jakis niepotrzbny syf


3) te techniki 'algorytmicznej ' optymalizacji (czyli a)odrzucanie/odfiltorowywanie
roboty do wyonania
b) 'linearyzacja' / czyli cos w stylu liczeni stratenego na jakosci ale szybszego
(jak np nie liczenie calych pierwiastkow a tylko przyblizonych, albo licznie ich
tylko na rogach kafelkow a pozniej interpolowanie liniowe)

wymianione sa charakterystyczne dla kodwowania grafiki ale raczej dadza sie jakos
uogolnic w pewnym sesnie na ogolene
metody algorycznej optymalizacji - i sam w to szedlem z ciekawosci ale moze to sie
przerodzic troche w robote rodem z jakiegos NASA czy cos (mowiac metaforycznie ) bo
okazuje sie ze kod ktory w oryginale ma Xliniejek po dowaleniu tej algorytmiki ma 10
razy
tyle - jest doalebnie mniej nieczytelny i diablenie zamkniety na poprawki - ale
dziala szybciej, po przepisywaniu na profesjonalnego asma pewnie jeszcze szybciej i
jeszcze bardziej nieczytelny i jeszcze bardziej zamkniety na zmiany

dlatego by nie klepac po proznicy w usenecie (bo ludzi nei eznaja sie na
optymalizacji ale klepia bzdury jak kompletne downy (np ze kompilator sam
zoptymalizuje - kompilator nie zoptymalizuje to jest totalna bzdura bo kompilator
tylko potrafi skompilowac co programista zapiesze by to optymalizowac tzreba to
przepisywac) mozna powiedzic tye;

1) optymalizacja moze duzo dawac ale maszkilak jej poziomow i typow - wbrew pozorom
mikrooptymalizacje na poziomie c sa mz jedna z najtanszych i najlepszych rzeczy jaka
mozna robic... warto tez rozumiec api jakiegios ie uzywa i system
(nie jest to optymalizacja el chodzi o poprawne rozumienie kodu)... te optymalizacje
algorytmiczne o ktorych tez downy z netu nawijaja tez mozna rozumeic dwojako, jako
wybor algorytmu do zrobienie czegos (co zwykle raczej nie jest trudne i kazdy kumaty
programista nie ma chyab z tym wiekszego problemu, bo czemu ma wybrac cos wolnego
zamiast czegos normalnego) ale tez do pisanie tych algorytmow ktore rozbudowaywuja
algorytm po to by dziala szybko np przez to odrzucani i linearyzowanie - ale to jest
troche ryzykowan apsrawa bo z prostego kodu dostejesz dlgi i bardzo techniczny...
schodzenie do poziomu recznego asma... jak ktos umie to cyba mozna ale to kolejna
doza roboty

i poza wszystkim tzreba pamietac ze
by cos zoptymalizowac najpierw trzeba to napisac w zwyklej wersji a z tym jest duzo
wiekszy problem... co z kolei jest pociecha dla tych ktorzy uzywaja wolnieszych
jezykow - faktycznie to ze cos jest wolniejsze wcale tego nie dyskwalifikuje, bo
chodzi o to byc cos
na poczatek wogole zrobic

by cos wogole zrobic z kolei trzeba miec odpowiednia pare by to moc zrobic i to jest
jeszcze inny problem itd itd