🚀 go-pugleaf

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ść.