Wpis z mikrobloga

@ItsFine: takie podejście to tylko w crudzie naszym powszednim, a nie w tym majstersztyku optymalizacji z końca ubiegłego stulecia

ps. w zasadzie można to pokryć to testami udowadniającymi jak pomijalnie mały jest błąd i nawet OP zrozumiałby że to ma sens (ʘʘ)

pps. ciekawe czy współcześnie jakimiś heurystycznymi algorytmami albo ML wynajduje się dużo podobnych optymalizacji
@dendrofag: wiesz - jeśli to jest kod z przełomu wieków, to ja się nie dziwię. Np w starym delphi, gdzie opiekuje się starym kodem, sama zamiana x/2 na 0.5*x przyśpiesza, ja wiem, Borland w optymalizacjach zawsze był lata świetlne za murzynami i niektóre kompilatory C juz potrafiły to optymalizowac wtedy, ale tak by zrozumieć niektóre zabiegi warto się cofnąć do czasów gdy kod powstawał.
@Kaczus2B: z drugiej strony kiedyś programiści poświęcali o wiele więcej czasu na optymalizację. Stosowali różne kruczki i sztuczki, żeby tylko wycisnąć ze sprzętu 110% jego potencjalnych możliwości.
Teraz po prostu dokupujesz kolejną kość pamięci, albo wymieniasz procesor na nowszy model i problem załatwiony.
@dendrofag: Tak, choć jak patrzę na to co generują przy optymalizacji obecne kompilatory, to często sam bym na to nie wpadł :) Zapas mocy procesora przydaje się przy kompilacji, bo optymalizator oraz checker może pohulać. Same warningi, które rzucał taki gcc4 a które wynajduje gcc9 to kolosalna róznica, dzięki temu można na prawdę wyłapać wiele pomyłek w kodzie.