On 17.12.2014 09:24, firr wrote:
> 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"

Bo jest. JEśli przepisałbyś to na asm, nie przyszpieszyłoby znacznie.
>
> 'algorytm' nie byl zmieniany, pierwsze wielkie przyspieszenie
> wystapilo przy zaminieniu sinusów div i sqrt na tablice,

To _jest_ zmiana algorytmu.

> (+ zmienieniu castow na inta na na linijke w asmie)

To też, czhoć to drobna zmiana.

> drugie po przepisaniu petli na kafelki, trzecie po recznym rozlozeniu
> petli i rozwinieciu na 4

A kazałeś geniuszu rozwinąć kompilatorowi pętle?

>>> 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

Co to -Ofast?

Nie ma niczego o pętlach. Skoro chces rozwijać,
czemu nie dasz -funroll-loops.

Zapomnialeś o parze
-fprofile-generate
-fprofile-use

pzdr
bartekltg