W dniu środa, 17 grudnia 2014 01:05:20 UTC+1 użytkownik firr napisał:
> 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

jeszcze mam w odwodzie wersje z intrisinkami na sse (acz watpie by pomogla
zauwazalnie pomogla ) podejrzewam ze carmack czy tam abrash jeszcze
przyoptymalizowaliby to moja wersje z 5 razy (5 to mzoe przesada ale cos w tym stylu)
prawda jest jednak ze optymalizowanie zzera czas, dwa tygodnie w plecy na samio
optymalizowanie tej petli na 10 sposobów
- po czym dwa tygodnie odpoczywania ze wzgledu na przeciazenie - czyli miesiac - na
optymalizacje jednej rzeczy

do góry

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.

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


pzdr
bartekltg

do góry

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,

do góry

W dniu 2014-12-17 09:24, firr pisze:
> W dniu środa, 17 grudnia 2014 03:01:18 UTC+1 użytkownik bartekltg napisał:

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

Czyli zmiana algorytmu - bo masz dane zbuforowane i z nich korzystasz, a
nie wyliczasz na bieżąco, to tak jakbyś pisał, że rendering trwa dłużej
niż wyświetlenie wyrenderowanej bitmapy.


> (+ zmienieniu castow na inta na na linijke w asmie)
> drugie po przepisaniu petli na kafelki, trzecie po recznym rozlozeniu petli i
rozwinieciu na 4

Bo kompilator nie napisze za ciebie programu



--
Kaczus
http://kaczus.ppa.pl

do góry

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)

do góry

W dniu środa, 17 grudnia 2014 09:40:17 UTC+1 użytkownik Tomasz Kaczanowski napisał:
> W dniu 2014-12-17 09:24, firr pisze:
> > W dniu środa, 17 grudnia 2014 03:01:18 UTC+1 użytkownik bartekltg napisał:
>
> >> 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,
>
> Czyli zmiana algorytmu - bo masz dane zbuforowane i z nich korzystasz, a
> nie wyliczasz na bieżąco, to tak jakbyś pisał, że rendering trwa dłużej
> niż wyświetlenie wyrenderowanej bitmapy.
>
>
> > (+ zmienieniu castow na inta na na linijke w asmie)
> > drugie po przepisaniu petli na kafelki, trzecie po recznym rozlozeniu petli i
rozwinieciu na 4
>
> Bo kompilator nie napisze za ciebie programu
>
>
>
chcesz to sobie nazywaj to zmina algorytmu ;/ wolna wola, ja zmiana algorytmu nazywam
cos innego

do góry

On Wednesday, December 17, 2014 9:40:17 AM UTC+1, Tomasz Kaczanowski wrote:
> W dniu 2014-12-17 09:24, firr pisze:
> > W dniu środa, 17 grudnia 2014 03:01:18 UTC+1 użytkownik bartekltg napisał:
>
> >> 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,
>
> Czyli zmiana algorytmu - bo masz dane zbuforowane i z nich korzystasz, a
> nie wyliczasz na bieżąco, to tak jakbyś pisał, że rendering trwa dłużej
> niż wyświetlenie wyrenderowanej bitmapy.
Moze chodziło o to, że zmiana na buforowane wyniki była dokonana
jeszcze w C/C++ :D

> Bo kompilator nie napisze za ciebie programu
Moim zdaniem, dobry kompilator, powinien trochę zmieniać algorytm.
Nie mogę pojąć dlaczego niektóre wersje kompilatorów generują
gorszy kod dla tablic niż wskaźników. Ostatnio Bartek mierzył, nie
wiem czy pamiętacie.

Pozdrawiam

do góry

W dniu 2014-12-17 o 10:11, M.M. pisze:
> Moim zdaniem, dobry kompilator, powinien trochę zmieniać algorytm.
> Nie mogę pojąć dlaczego niektóre wersje kompilatorów generują
> gorszy kod dla tablic niż wskaźników. Ostatnio Bartek mierzył, nie
> wiem czy pamiętacie.

Dobry kompilator powinien umożliwiać aby programista sam zmienił
algorytm na wydajniejszy cały czas używając języka wysokiego poziomu bez
żadnych wstawek.

do góry

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

do góry

On 17.12.2014 09:51, firr wrote:
> W dniu środa, 17 grudnia 2014 09:40:17 UTC+1 użytkownik Tomasz Kaczanowski napisał:
>> W dniu 2014-12-17 09:24, firr pisze:
>>> W dniu środa, 17 grudnia 2014 03:01:18 UTC+1 użytkownik bartekltg napisał:
>>
>>>> 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,
>>
>> Czyli zmiana algorytmu - bo masz dane zbuforowane i z nich korzystasz, a
>> nie wyliczasz na bieżąco, to tak jakbyś pisał, że rendering trwa dłużej
>> niż wyświetlenie wyrenderowanej bitmapy.
>>
>>
>>> (+ zmienieniu castow na inta na na linijke w asmie)
>>> drugie po przepisaniu petli na kafelki, trzecie po recznym rozlozeniu petli i
rozwinieciu na 4
>>
>> Bo kompilator nie napisze za ciebie programu
>>
>>
>>
> chcesz to sobie nazywaj to zmina algorytmu ;/ wolna wola, ja zmiana algorytmu
nazywam cos innego


A nazywaj sobie jak chcesz. Jest to zmiana sensu, sposobu działania
programu, Kompilator nie może tego robić.

pzdr
bartekltg

do góry