[ZawzietyRobaczek]

#optymalizacja #jezykc #programowanie #gamedev Pozbyłem się brancha ( ͡° ͜ʖ ͡°) pijcie ze mno kompot

[roomcayz]

@ZawzietyRobaczek jak ja się cieszę że nie robię w gamedev i nie muszę robić takich "optymalizacji"

[groman43]

@ZawzietyRobaczek: Gratulację, odkryłeś numer, który jest starszy od Ciebie o co najmniej 50 lat ( ͡° ͜ʖ ͡°)

[ZawzietyRobaczek]

@groman43: grunt to grzebać w kodzie i to znaleźć :)

[groman43]

@ZawzietyRobaczek: Szczerze, w trzeciej dekadzie XXI wieku takie rzeczy powinnien robić kompilator, a nie programista. Serio, gdybym był na Twoim miejscu to:
- porównałbym wygenerowany assembly, żeby sprawdzić czy Twoje zmiany w ogóle coś dały, czy to tylko sztuka dla sztuki
- Zamiast usuwać branche na ślepo, najpierw sprofilowałbym kod. Określił, które kawałki wykonują się nie tylko najdłużej, ale również najczęściej i skupił się na tych fragmentach

[ZawzietyRobaczek]

@groman43: @roomcayz: no wlasnie porownalem kod z asemblera i sie okazalo ze zrobił to lepiej i pierwsza wersja byla lepsza.. :-/

[PlesniakPospolity]

@ZawzietyRobaczek: optymalization -> optimization

[Moroder]

@ZawzietyRobaczek: to po co to w ogóle zacząłeś optymalizować? xd

[ZawzietyRobaczek]

@Moroder: @groman43: koduje pod wolniejsza architekturę, i szukam gdzie się da po prostu

[czarny_i_zly]

@ZawzietyRobaczek: Ogólnie po amerykańsku prawidłowo jest 'optimization', jeśli chcesz użyć koniecznie 'z'. Brytole dopuszczają 'optimaliSation' przez 's', ale poprawniej jest 'optimisation' wg Collinsa.

[Moroder]

@ZawzietyRobaczek: ale na pewno trzeba? zazwyczaj nie warto optymalizować za wcześnie, bo może się okazać, że chodzi już wydajnie

[groman43]

@ZawzietyRobaczek: ( ͡°( ͡° ͜ʖ( ͡° ͜ʖ ͡°)ʖ ͡°) ͡°)

Na podstawie pierwszej wersji, kompilator łatwiej może określić to tak naprawdę chcesz zrobić, dlatego łatwiej może wygenerować bardziej optymalny kod. Jeśli już, to może pomyślałbym o wykorzystaniu czegoś w rodzaju makr likely / unlikely jeśli masz taką możliwość. Ale z mojego doświadczenia wynika, że bardzo rzadko

[ZawzietyRobaczek]

@groman43: m68k

[groman43]

m68k

@ZawzietyRobaczek: Ło panie, w którym muzeum to znalazłeś? ( ͡° ͜ʖ ͡°)

[ZawzietyRobaczek]

@groman43: hobby ( ͡° ͜ʖ ͡°)

[afe1]

@ZawzietyRobaczek: no nie wiem. Żeby wykonać drugą linijkę, procesor musi czekać na wykonanie pierwszej i przypisanie do zmiennej i dopiero wtedy może korzystać z tej zmiennej (data dependance). W przypadku if else może coś by spekulacyjnie zrobił?

Policz cykle ( ͡° ͜ʖ ͡°)

[Saly]

@ZawzietyRobaczek: xd https://youtu.be/2EWejmkKlxs?t=1941

[Saly]

@ZawzietyRobaczek: jak już tak chcesz cudować to ogarnij sobie LTO + PGO, kompilator potrafi czynic cuda jak wie jakie są prawdopodobieństwa branchy

[alex-fortune]

@roomcayz: w gruncie rzeczy ta optymalizacja prawie na stówę nic nie da bo każdy nowoczesny kompilator sprowadziłby rzecz do czegoś podobnego albo szybszego.

[ponton]

@ZawzietyRobaczek na pewno jest szybciej? wziąłeś pod uwagę branch prediction?

[ZawzietyRobaczek]

@ponton: @alex-fortune: @Saly: nie bylo jednak roznicy, kod wygeneraowany przez asm byl bardzo podobny w obu przypadkach ale ten pierwszy przed optymalziacja mial 2-3 instrukcji mniej.. uzywam gcc 6.0.5b na starej architekturze m68k wiec nie bedzie tu cudów ktore daja nowe super procesory :)