-
Data: 2014-12-17 12:11:08
Temat: Re: Szukam benchmarków
Od: firr <p...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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
Następne wpisy z tego wątku
- 17.12.14 12:25 firr
- 17.12.14 12:48 bartekltg
- 17.12.14 14:00 M.M.
- 17.12.14 14:24 g...@g...com
- 17.12.14 15:27 M.M.
- 17.12.14 15:33 g...@g...com
- 17.12.14 16:25 M.M.
- 17.12.14 16:39 firr
- 17.12.14 16:52 firr
- 17.12.14 16:55 Borneq
- 17.12.14 16:56 firr
- 17.12.14 17:08 bartekltg
- 17.12.14 17:15 bartekltg
- 17.12.14 17:21 M.M.
- 17.12.14 17:25 M.M.
Najnowsze wątki z tej grupy
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
- Ada 2022 Language Reference Manual to be Published by Springer
Najnowsze wątki
- 2024-11-02 piszę list do św Mikołaja
- 2024-11-01 karta SIM nie działa w konkretnym smartfonie.
- 2024-11-01 Mamy WZROST! O 50% wzrosła ilość kredytów gotówkowych
- 2024-11-01 Warszawa => Expert Recruiter 360 <=
- 2024-11-01 Warszawa => Technical Leader (Java Background) <=
- 2024-11-01 Warszawa => Account Manager - Usługi rekrutacyjne <=
- 2024-11-01 Warszawa => Head of International Freight Forwarding Department <=
- 2024-11-01 Warszawa => Programista Dynamics 365 CRM <=
- 2024-11-01 Warszawa => Dynamics 365 CRM Developer <=
- 2024-11-01 Warszawa => Junior Rekruter <=
- 2024-11-01 Chrzanów => Specjalista ds. PR Produktowego <=
- 2024-11-01 Białystok => Full Stack web developer (obszar .Net Core, Angular6+) <
- 2024-11-01 Łódź => Frontend Engineer (Three.js) <=
- 2024-11-01 Warszawa => Junior Rekruter <=
- 2024-11-01 Gdańsk => Programista Full Stack .Net <=