W dniu środa, 17 grudnia 2014 11:57:11 UTC+1 użytkownik bartekltg napisał:
> 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?
>

takimi burackimi uwagami wiele nie zyskasz, to troche nie moj poziom
moze idz sobie pokonwersowac z kolegami bo ja na tego typu ćwoko-dyskusje jakos sie
nie łapie - raczej popatrz na swoja wlasna glupote dyskutujesz z czyms czego ja wcale
nie twierdze i co mnie wogole nie obchodzi) i jeszcze w swojej glupocie uzywasz
słówek, dzieki ale
troszke zbyt traci głupotą jak na moje standardy ;o

jesli masz jakies zazuty to zwroc dokladnie uwage co ja pisze (i do czego sie odnosze
a do czego nie)

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

W dniu środa, 17 grudnia 2014 11:58:42 UTC+1 użytkownik bartekltg napisał:

>
> A nazywaj sobie jak chcesz. Jest to zmiana sensu, sposobu działania
> programu, Kompilator nie może tego robić.
>
Dzieki za pozwolenie ;o ja rowniez pozwalam ci uzywac swojego glupawego nazewnictwa,
problem w tym ze juz chyba wiecej nie pogadamy rozmowy na takim niklym poziomie juz
przestaja mnie wogole bawic (pomysle jeszcze ale wątpie)

do góry

On 17.12.2014 12:25, firr wrote:
> W dniu środa, 17 grudnia 2014 11:58:42 UTC+1 użytkownik bartekltg
> napisał:
>
>>
>> A nazywaj sobie jak chcesz. Jest to zmiana sensu, sposobu
>> działania programu, Kompilator nie może tego robić.
>>
> Dzieki za pozwolenie ;o ja rowniez pozwalam ci uzywac swojego
> glupawego nazewnictwa, problem w tym ze juz chyba wiecej nie pogadamy
> rozmowy na takim niklym poziomie juz przestaja mnie wogole bawic
> (pomysle jeszcze ale wątpie)
>

http://rtfm.killfile.pl/#lajza
W skrócie: piszesz głupoty, zostałeś o tym poinformowany.
Nie becz z tego powodu, bo nie wypada.

bartekltg

do góry

On Wednesday, December 17, 2014 10:35:46 AM UTC+1, Borneq wrote:
> 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.

Moim zdaniem kompilator powinien być na tyle bystry, żeby w
pętli zmienić:

tablica[i]

na

*tablica++

Jeśli to w danym przypadku przyspiesza, rzecz jasna.
Tak samo powinien wyrugować zmienną 'i', jeśli ona
spowalnia i nie jest dalej potrzebna.

Może jeszcze dodam: mam w dupie czy to się nazywa zmiana
algorytmu, czy zmiana czegoś innego. Optymalizaotr powinien
sprawdzić kilka odmian i wybrać najszybszą.

Pozdrawiam

do góry

W dniu środa, 17 grudnia 2014 03:01:18 UTC+1 użytkownik bartekltg napisał:
> > 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.

Jezeli dana procedura (taka jak np. liczenie sinusa) gwarantuje,
ze dla tego samego argumentu zawsze uzyskamy ten sam wynik, to nie
ma zadnego powodu, dla ktorego kompilator nie mialby sam tablicowac
wynikow. Nazywanie tego rodzaju optymalizacji "zmiana algorytmu"
wydaje sie jednak dosc pretensjonalne

Poza tym, jezeli nie mialoby to wplywu na obserwowalne zachowanie programu,
to nie widze powodu, dla ktorego kompilator nie mialby w okreslonych
okolicznosciach zamieniac bubblesorta na qsorta (choc w tym kontekscie
oczywiscie stwierdzenie "zamiana algorytmu" wydaje sie jak najbardziej na miejscu).
Istnieja ciekawe metody dotyczace optymalizacji algorytmow,
opisane np. tutaj:
http://repository.readscheme.org/ftp/papers/topps/D-
170.ps.gz

> > jeszcze kombinowalem z rugowaniem castow i
>
> To samo. Każesz kompialtorowi liczyć danymi zmiennymi, musi nimi
> liczyć.

Nie bardzo rozumiem te uwage, ale znow: jezeli kompilator moze w jakims
kontekscie dokonac czesciowej ewaluacji, to nie ma istotnego powodu, dla
ktorego nie mialby tego robic

do góry

On Wednesday, December 17, 2014 2:24:57 PM UTC+1, g...@g...com wrote:
> Jezeli dana procedura (taka jak np. liczenie sinusa) gwarantuje,
> ze dla tego samego argumentu zawsze uzyskamy ten sam wynik
Wystarczy ze gwarantuje taką samą dokładność dla określonego zbioru
argumentów.


Swoją drogą, szkoda że w C++ nie można przy argumencie procedury
napisać, że dany argument będzie przyjmował wartości tylko z małego
zbioru. Wtedy kompilator miałbym lepsze możliwości optymalizacji.


np.
f( int x@{1:50%,0:20%,2:10%,other} ) {
return sin(x);
}

Kompilator mógłby stablicować dla sin dla 1, 0 i 2, a że 1
przychodzi statystycznie w 50%, to mógłby 'górnym ifem' sprawdzać,
czy x==1.

if( x==1 ) return sin(1);
if( x==0 ) return sin(0);
if( x==2 ) return sin(2);
return sin(x);

Z kolei gdy się nie poda statystyki wystąpień, to kompilator mógłby
wziąć wartości z pgo.

Dalej, gdy nie ma other, to w ogóle kompilator mógłby wygenerować
ultra zoptymalizowany kod:

f( int x@{1:60%,0:40%} ) {
return x==1 ? sin(1) : sin(0);
}


Pozdrawiam

do góry

W dniu środa, 17 grudnia 2014 15:27:39 UTC+1 użytkownik M.M. napisał:
> On Wednesday, December 17, 2014 2:24:57 PM UTC+1, g...@g...com wrote:
> > Jezeli dana procedura (taka jak np. liczenie sinusa) gwarantuje,
> > ze dla tego samego argumentu zawsze uzyskamy ten sam wynik
> Wystarczy ze gwarantuje taką samą dokładność dla określonego zbioru
> argumentów.
>
>
> Swoją drogą, szkoda że w C++ nie można przy argumencie procedury
> napisać, że dany argument będzie przyjmował wartości tylko z małego
> zbioru. Wtedy kompilator miałbym lepsze możliwości optymalizacji.

Mozna. Takie cos nazywa sie "enum"

do góry

On Wednesday, December 17, 2014 3:33:10 PM UTC+1, g...@g...com wrote:
> Mozna. Takie cos nazywa sie "enum"
Enum ma zbyt ograniczone możliwości do tego celu. Nie działa na floatach,
nie działa na stringu, nie działa na zakresach. Tak, dałem przykład
na intach, ale generalnie chodziło mi o wygodne definiowane
dopuszczalnych wartości.

Pozdrawiam

do góry

W dniu środa, 17 grudnia 2014 15:27:39 UTC+1 użytkownik M.M. napisał:
> On Wednesday, December 17, 2014 2:24:57 PM UTC+1, g...@g...com wrote:
> > Jezeli dana procedura (taka jak np. liczenie sinusa) gwarantuje,
> > ze dla tego samego argumentu zawsze uzyskamy ten sam wynik
> Wystarczy ze gwarantuje taką samą dokładność dla określonego zbioru
> argumentów.
>
>
> Swoją drogą, szkoda że w C++ nie można przy argumencie procedury
> napisać, że dany argument będzie przyjmował wartości tylko z małego
> zbioru. Wtedy kompilator miałbym lepsze możliwości optymalizacji.
>
>
> np.
> f( int x@{1:50%,0:20%,2:10%,other} ) {
> return sin(x);
> }
>
> Kompilator mógłby stablicować dla sin dla 1, 0 i 2, a że 1
> przychodzi statystycznie w 50%, to mógłby 'górnym ifem' sprawdzać,
> czy x==1.
>
> if( x==1 ) return sin(1);
> if( x==0 ) return sin(0);
> if( x==2 ) return sin(2);
> return sin(x);
>
> Z kolei gdy się nie poda statystyki wystąpień, to kompilator mógłby
> wziąć wartości z pgo.
>
> Dalej, gdy nie ma other, to w ogóle kompilator mógłby wygenerować
> ultra zoptymalizowany kod:
>
> f( int x@{1:60%,0:40%} ) {
> return x==1 ? sin(1) : sin(0);
> }
>
jesli statycznie wiesz co to bezie to sam sobie mozesz to napisac w dobrej kolejnosci
zamiast troche szpecic zrodlo tymi procentami; jesli nie to lepiej jednak by
kompilatr sobie sam ta statystyke trzasnal (i tak jakos slabo wierze w skutecznosc
tego rodzaju optymizacji - za to chyba zgodzilbym sie ze przydaloby sie definiowanie
statycznych okrojonych typow np float_od_0_do_1 albo int_od_0_do_100)

do góry

W dniu środa, 17 grudnia 2014 16:39:51 UTC+1 użytkownik firr napisał:
> W dniu środa, 17 grudnia 2014 15:27:39 UTC+1 użytkownik M.M. napisał:
> > On Wednesday, December 17, 2014 2:24:57 PM UTC+1, g...@g...com wrote:
> > > Jezeli dana procedura (taka jak np. liczenie sinusa) gwarantuje,
> > > ze dla tego samego argumentu zawsze uzyskamy ten sam wynik
> > Wystarczy ze gwarantuje taką samą dokładność dla określonego zbioru
> > argumentów.
> >
> >
> > Swoją drogą, szkoda że w C++ nie można przy argumencie procedury
> > napisać, że dany argument będzie przyjmował wartości tylko z małego
> > zbioru. Wtedy kompilator miałbym lepsze możliwości optymalizacji.
> >
> >
> > np.
> > f( int x@{1:50%,0:20%,2:10%,other} ) {
> > return sin(x);
> > }
> >
> > Kompilator mógłby stablicować dla sin dla 1, 0 i 2, a że 1
> > przychodzi statystycznie w 50%, to mógłby 'górnym ifem' sprawdzać,
> > czy x==1.
> >
> > if( x==1 ) return sin(1);
> > if( x==0 ) return sin(0);
> > if( x==2 ) return sin(2);
> > return sin(x);
> >
> > Z kolei gdy się nie poda statystyki wystąpień, to kompilator mógłby
> > wziąć wartości z pgo.
> >
> > Dalej, gdy nie ma other, to w ogóle kompilator mógłby wygenerować
> > ultra zoptymalizowany kod:
> >
> > f( int x@{1:60%,0:40%} ) {
> > return x==1 ? sin(1) : sin(0);
> > }
> >
> jesli statycznie wiesz co to bezie to sam sobie mozesz to napisac w dobrej
kolejnosci zamiast troche szpecic zrodlo tymi procentami; jesli nie to lepiej jednak
by kompilatr sobie sam ta statystyke trzasnal (i tak jakos slabo wierze w skutecznosc
tego rodzaju optymizacji - za to chyba zgodzilbym sie ze przydaloby sie definiowanie
statycznych okrojonych typow np float_od_0_do_1 albo int_od_0_do_100)

wtedy moglby zasadniczo stablicowac po kryjomu takiego sinusa lub inne nawet zlozone
wtrazenia (wziawszy pod uwage moje wyniki ze tablicowanie jednak duzo daje to
moglbybyc wybitnie korzystne 9typu wlasnie jak mowie skoki wydajnosci typu 50 razy) -

zalety: automatycznie sie robi i spora czytelnosc kodu, z kolei reczna wersja
bardziej pracochlonna ale moglabbyc ciagle troche z przodu ze wzgledu na jawny dostep
do tych malych tablic

do góry