W dniu wtorek, 16 grudnia 2014 23:53:06 UTC+1 użytkownik M.M. napisał:
> On Friday, July 18, 2014 10:34:42 AM UTC+2, Wojciech Muła wrote:
> > Wstawki asemblerowe robi się dla celów wydajnościowych,
> > kompilatory nie zawsze dają radę.
> > A już kompletnie nie
> > dają sobie rady w nietrywialnych przypadkach.
> Temat wraca. Nie wiem co to są nietrywialne przypadki.
> Moim zdaniem kompilatory rzadko generują optymalny kod,
> ale często nie stanowi to problemu. W niektórych wersjach
> kompilatorów miałem wrażenie, że mała wstawka w asemblerze
> pogarszała wydajność.
>
ostatnio mialem drastyczny przyklad na to ze to co powtarzaja niektorzy ze kompilator
zoptymalizuje sam albo ze generuje dobry kod to sa kompletne bajki
9byc moze generuje dobry kod ale z dobrego ciezko zoptymalizowanego zrodla)

konkretny przypadek z tym kodem gdzie chailem wyswietlic teksturowaną kopułe
w trojwymiarowym prototypie (co obejmuje wyznaczenie wektora kierunku w 3d dla
kazdegio piksela ekranu i zrobieni look up w teksturze na podstawie kierunku)

inicjalna wersja trwala jakies 100 czy nawet 150 ms ms a to glownie dziki temu ze
czas zarly dwa sinusy i pierwiastek na piksel jeszcze z jakims dzieleniem i
rzutowaniami (jak uzyjesz sinusa w kodzie to program jest wydajnosciowym trupem tak
bardzo sinus jest wolny) po stablicowaniu sinusów i normalizacji i jeszcze ze dwu
dniach glowienia sie nad petla czas spadl do 20 i w koncu do 13 milisekund 9prawie 10
razy szybciej niz normalny kod dla gcc) ciegle uwazalem ze to za duzo i zaczalem
przepisywac kod na kafelki gdzie mogelem zrobic na kafelkach pewna interpolacje i
pewne tam drobne rozroznienia, to bylo troche trudne ale spowodowalo ze cza sspadl do
6-10 ms, 910-20 razy sszybciej "niz gcc", jeszcze kombinowalem z rugowaniem castow i
rozwijaniem petli na kafelku i co sie okazalo - zanotowalem zjazd do wlaciwie 2-5 ms
(te 5 ms moglbym jeszcze obnizyc ale to znowu wiaze sie z kolejnymi przepisakami
ktore mi sie nie chcialo robic - wlasciwie to normalny czas tego co mocniej
przyoptymalizowalem spadł do 2 ms (co juz jest mega imponujacym wynikiem) - 50 razy
szybciej wzgledem podejscia ze nie ma co optymalizowac bo nic nie pomoze ;-0