W dniu środa, 17 grudnia 2014 03:01:18 UTC+1 użytkownik bartekltg napisał:
> On 17.12.2014 01:05, firr wrote:
> > 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",
>
> Zaraz, wkurzasz się, zę kompilator nie zmienił ci algoruytmu na inny?
> Znów odpływasz. Kompilator nie może zmienić bublesorta na qsorta.
> Zmieniłeś algorytm na szybszy, a mniej dokłądny, to masz
> przyszpieszenie, nie ma to nic wspolnego z jakością generowanego kodu.
>
nmie 'wkurzam sie' tylko odnosze sie do pewnych twierdzen ze jak napiszesz kod
normalnie to to co gcc wygeneruje "bedzie
w miare szybkie"

'algorytm' nie byl zmieniany, pierwsze
wielkie przyspieszenie wystapilo przy zaminieniu sinusów div i sqrt na tablice,
(+ zmienieniu castow na inta na na linijke w asmie)
drugie po przepisaniu petli na kafelki, trzecie po recznym rozlozeniu petli i
rozwinieciu na 4


> > jeszcze kombinowalem z rugowaniem castow i
>
> To samo. Każesz kompialtorowi liczyć danymi zmiennymi, musi nimi
> liczyć.
>
> > 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
>
> Nie rozwinął pętli?
> A jakie były flagi przy kompilacji? ;>
>

-O2 -Ofast -w -c sky_dome.c -funsafe-math-optimizations -mrecip -ffast-math -fno-rtti
-fno-exceptions -mtune=generic -mfpmath=both

-march ustawiam roznie pentium3 pentium4 core2,