W dniu środa, 17 grudnia 2014 09:24:26 UTC+1 użytkownik firr napisał:
> 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
>
ps zalezy co rozumiec przez algorytm, mz to nie byla zmian algorytmu (typu z
kwadratowego na liniowy itp), zmiany procedur (przestawianie albo lekkie zminay) moga
byc bo na tym polega optymizacja, ale strumien przetwarzanych danych nie byl
zmniejszany, na tch kafelkach zrobilem mala czesciową liniowa interpolacje, rozniez
pomagaja drobne sztuczki (typu dzielenie przez zero)

- i tak to co mam moglbym przepisywc dalej: 1) calkiem na inty bo teraz mam mix
zewnetrzny indeks na floatach tylko wewn na fixedpointach 2) rzadko wystepujavca
czesc kafelkow wogole nie jest zoptymizowana bo mi sie nie chcialo a to one zdaje sie
odpowiadaja za ten
dolny limit 5 ms 3) przepisanie na inytrinsinki sse (bylyby to calkowite
integer a te chyba nie zrobia wielkiej roznicy) 4) ew dokladne przyjjrzenie sie
petlon na poziomie czystego asma

(tym pewnie kiedys sie zajme ale na razie zżarlo mi sporo czasu i ta wersja co mam
juz jest jako tako funkcjonalna, osobiscie wolalbym i tak by kompy byly po prostu
szybsze wtedy prosty kod by dobrze dzialal a sam wolalbym pisac w prostym kodzie)