Article View: pl.comp.lang.c
Article #310021Re: Optymalizacja kodu
From: M.M.
Date: Thu, 26 Dec 2019 04:03
Date: Thu, 26 Dec 2019 04:03
79 lines
4890 bytes
4890 bytes
On Thursday, December 26, 2019 at 2:10:51 AM UTC+1, (fir) wrote:
> W dniu środa, 25 grudnia 2019 14:25:07 UTC+1 użytkownik M.M. napisał:
> > On Wednesday, December 25, 2019 at 12:01:32 PM UTC+1, Maciek Godek wrote:
> > > W dniu środa, 25 grudnia 2019 11:55:33 UTC+1 użytkownik Maciek Godek napisał:
> > >
> > > > - sprawdzić, na ile kosztowna będzie instrukcja warunkowa (może być kosztowna, ale nie musi, bo teoretycznie - na Intelu przynajmniej - kompilator może wciągnąć rejest znaczników w wir operacji arytmetycznych, efektywnie nie wykonując instrukcji skoku warunkowego)
> > >
> > > Zresztą nawet w C można to sobie zarytmetyzować:
> > >
> > > int x = random() & odpowiednia_maska_bitowa;
> > > return x - (x > zakres)*(potęga_dwójki - zakres);
> >
> > Kiedyś ktoś pokazywał kod w asemblerze jak kompilator zoptymalizował właśnie
> > operację reszty z dzielenia całkowitego. Nie pamiętam szczegółów, ale efekt
> > był bardzo imponujący. Nie wiem czy w procesory są wbijane tego typu
> > optymalizacje, ale na pewno mogą być.
> >
> > Teraz mnie zamurowało na widok dużych różnic w czasie z powodu nieznacznych
> > zmian w kodzie. Tutaj na forum wrzuciłem tylko cztery przykłady, na
> > szybko wyciągnięte z większego kodu. W ogóle zrobiłem więcej podobnych
> > eksperymentów i zależność wydajności od drobnych zmian w kodzie jest jeszcze
> > dziwniejsza. Np. gdy mam własnej roboty wektor a w nim test z funkcją abort:
> >
> > T& operator()(const size_t i) {
> > if( i >= SIZE ) abort();
> > return data[i];
> > }
> >
> > To działa o 10% szybciej niż gdy mam samo return:
> >
> > T& operator()(const size_t i) {
> > return data[i];
> > }
> >
> > Czyżby kompilator umiał wywnioskować coś o kodzie na podstawie wywołania
> > abort - wszak to wywołanie znamienne.
> >
> > Inna sprawa: Zwykle używam std::vector, albo QVector. Czasami gdy chcę
> > zoptymalizować kod, to biorę wskaźniki na dane z tych kontenerów, a kontenery
> > tylko (i aż!) ułatwiają zarządzanie pamięcią i wykonanie operacji które nie
> > są krytyczne dla wydajności. Ostatnio spróbowałem wziąć wskaźniki z new, z
> > std::array i z tablicy o stałym rozmiarze normalnie zadeklarowanej w programie.
> > Wydaje się że to wszystko jest to samo, bo potem operacje są wykonywane na
> > wskaźnikach. Jednak gdy używam new to program działa najszybciej - znowu nie
> > rozumiem dlaczego.
> >
> > Pozdrawiam
>
> testy powinno sie robic raczej w petli,
> tak byto co testowane sie 'rozgrzalo' ;c
> (pozatym jak sie mierzy w petli to widac ze wyniki czasem nieco oscyluja od przebiegu do przebiegu (zwykle nie jakos bardzoa le jednak)
>
> jak ja cos mierze zawsze mierze w petli takim pojedynczym przebiegom bym nie wierzyl - byc moze sa dobre ale nie wiem, bo nigdy ich nie uzywam
Dla pewności zrobiłem jeszcze jedna pętlę:
czasy[] = {0,0,0....}
while( true ) {
i = 0;
start = time();
test1()
czasy[i++] += time() - start;
start = time();
test2()
czasy[i++] += time() - start;
start = time();
test3()
czasy[i++] += time() - start;
......
}
Sumują się czasy wielu testów wykonywanych na przemian, stan komputera powinien
byś statystycznie taki sam dla wszystkich testów.
Pozdrawiam
Technical Details
Message-ID:
<b020d7c6-b6d6-4496-abca-37ed9c5217dd@googlegroups.com>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!feeder.erje.net!2.eu.feeder.erje.net!news.uzoreto.com!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.160.216.MISMATCH!g89no9042755qtd.0!news-out.google.com!w29ni69qtc.0!nntp.google.com!g89no9042746qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mailReferences:
<ed3041b7-c05f-43f3-887a-9a12a9633741@googlegroups.com> <b010dc08-d015-4a47-88be-75fa3b91cd07@googlegroups.com> <c13192a2-18b8-4342-ad49-6a90cf36a636@googlegroups.com> <ffcbee1e-596b-4120-95ac-ac0d8d2d5e5d@googlegroups.com> <1c73c0a7-ab48-412e-8b00-e110bdca01d5@googlegroups.com>Show Full Headers
Complete Article Headers
X-Received: by 2002:ad4:5144:: with SMTP id g4mr34300723qvq.179.1577332998692; Wed, 25 Dec 2019 20:03:18 -0800 (PST) X-Received: by 2002:a25:be53:: with SMTP id d19mr30887557ybm.303.1577332998473; Wed, 25 Dec 2019 20:03:18 -0800 (PST) Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!feeder.erje.net!2.eu.feeder.erje.net!news.uzoreto.com!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.160.216.MISMATCH!g89no9042755qtd.0!news-out.google.com!w29ni69qtc.0!nntp.google.com!g89no9042746qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: pl.comp.lang.c Date: Wed, 25 Dec 2019 20:03:18 -0800 (PST) In-Reply-To: <1c73c0a7-ab48-412e-8b00-e110bdca01d5@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=77.254.46.242; posting-account=xjvq9QoAAAATMPC2X3btlHd_LkaJo_rj NNTP-Posting-Host: 77.254.46.242 References: <ed3041b7-c05f-43f3-887a-9a12a9633741@googlegroups.com> <b010dc08-d015-4a47-88be-75fa3b91cd07@googlegroups.com> <c13192a2-18b8-4342-ad49-6a90cf36a636@googlegroups.com> <ffcbee1e-596b-4120-95ac-ac0d8d2d5e5d@googlegroups.com> <1c73c0a7-ab48-412e-8b00-e110bdca01d5@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <b020d7c6-b6d6-4496-abca-37ed9c5217dd@googlegroups.com> Subject: Re: Optymalizacja kodu From: "M.M." <mmarszik@gmail.com> Injection-Date: Thu, 26 Dec 2019 04:03:18 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit