On 17.12.2014 14:24, g...@g...com wrote:
> 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

Żeby zmienił sposób liczenia algorytmu - nie ma problemu.
Tak robi. Mi wszytko jedno, czy sin będzie policzony
koprocesorem czy szeregiem pędzonym SSE.
Natomiast zamiana na stablicowanie (nie w tym przypadku, tablica
o gęstości precyzyjnej jak sin[x] z interpolacją
liniową czy nawet kwadratową jest niepraktyczni duża ) powinna być
świadomą decyzją programisty.
Lepszym przykładem byłby dwumian newtona wielokrotnie liczony
dla małych parametrów. Czasem trzymam sobie go w pamięci,
ale czasem cache możę być znacznie przydatniejsze gdzie indziej,
i te kilka pętli jest lepszym wyjściem.


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

A skąd kompilator ma wiedzieć, co mam na myśli.
To, że potrzebuję akurat stabilnego sortowania będzie w stanie wyłapać?
Pamiętaj, że kompilator na zanalizować kod, a nie widzi intencje przez
użycie sort czy stable_sort.
A może zawsze ten algorytm sortuje jedynie malutkie tablice.
Albo wstępnie posortowane (dla insertsorta).

Kompilator musiałby zrozumieć nie tylko kod, ale i intencje
piszącego, oraz to, czy jest baranem, czy taki a nie inny
sposób przetwarzania danych wynika z jakiejś głębszej analizy.


> Istnieja ciekawe metody dotyczace optymalizacji algorytmow,
> opisane np. tutaj:
> http://repository.readscheme.org/ftp/papers/topps/D-
170.ps.gz

Bardzo dokładnie się nie wczytałem, ale czy rozwiązywanie
sporych NP zupełnych problemów grafowych podczas kompilacji
nie jest chwilowo przesadą? ;-)

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

Masz dwa programy. Jeden liczy coś intami, drugi na float.
Wyniki _NIE_ bądą identyczne, poza przypadkami, gdzie obłożymi
warunkami praktycznie wszystko.

Oczywiście, że liczenie pewnyych rzeczy na raz, najlepiej w czasie
kompilacji, po wyciągnieciu prez pętle jest przydatne. Nawet
powszechnie mowimy kompilatorowi, by się IEEE za bardzo przy tym
nie przejmował.

Ale to nie jest to, o czym była tu mowa.

pzdr
bartekltg