🚀 go-pugleaf

On Wednesday, December 25, 2019 at 10:49:29 PM UTC+1, Maciek Godek wrote:
> W dniu środa, 25 grudnia 2019 21:49:10 UTC+1 użytkownik M.M. napisał:
> > On Wednesday, December 25, 2019 at 8:52:44 PM UTC+1, Maciek Godek 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.
> > > 
> > > Ostatnio wrzucałem na pl.comp.programming linka do tej prezentacji:
> > > https://www.youtube.com/watch?v=r-TLSBdHe1A
> > > 
> > > Obczaj sobie narzędzia od tego gościa, bo może się okazać, że zmiana katalogu, z którego odpalasz program, będzie miała podobny wpływ na wydajność.
> > 
> > Chyba niemożliwe, zmiana katalogu może mieć 10-cio krotny wpływ na wydajność?
> 
> Wcześniej pisałeś, że o 10% szybciej

Pomiędzy wersją najszybszą a najwolniejszą mam 90% lub 1000% - zależy jak 
liczyć. Różnice pomiędzy wersją najszybszą a najwolniejszą są w moim odczuciu
kosmetyczne. NP. są wskaźniki zamiast indeksów:

return *i1++
zamiast
return buff[i1++]

Pamięć bufora jest pobierana z new, zamiast z pierwszego elementu tablicy:

buff = new typ[rozmiar];

zamiast

buff[rozmiar];
buff = &vector[0];

Jest minimalna optymalizacja instrukcji warunkowych.

Dziwi mnie przyspieszenie 10cio krotne z powodu takich niemal kosmetycznych
zmian.

Poza tym jest druga sprawa. Gdy dodaję kod, dokładnie gdy dodaję jedną
instrukcję warunkową:

if( index >= SIZE ) abort(); // Tak tę instrukcję.
return buff[index];

to program zaczął działać o 10% szybciej.

Ale... co ma wspólnego katalog z przyspieszeniem obliczeń na CPU? Swoją drogą,
odpalałem wszystkie testy z tego samego katalogu. 10% na czasie obliczeń
rzędu 100-200 sekund to chyba mierzalna wartość?

Kiedyś czytałem zdanie z którym nie do końca się zgadzam, że genialność języka
C i jego następcy C++ polega na tym, iż można kompilatorowi dzięki wskaźnikom
podpowiedzieć co ma być obliczane i kompilator generuje bardziej efektywny 
kod. Oczywiście w innych językach też można spotkać wskaźniki, a jeśli nie
ma wskaźników, to kompilator ma pewność że dane nie zostały zmienione za pomocą
dostępu przez wskaźniki  i może generować wydajniejszy kod. Przez wiele ostatnich
lat (około 10-12) widziałem, że drobne zmiany w kodzie nie wpływają na wydajność
obliczeń. Czy używałem wskaźnika, czy tablicy i indeksu, czy wektora, czy
makra, czy funkcji inline, czas był z reguły podobny, a nigdy nie był tak 
mocno różny. Ostatnio widzę że z powrotem dzięki kilku drobnym eksperymentom 
cały duży program można przyspieszyć np. dwa razy, a malutką procedurę nawet
10 razy. Co się stało? Używam kompilatora:

g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Pozdrawiam


Pozdrawiam