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