On Tue, 21 Dec 2010 20:04:53 +0100, Wojciech Jaczewski
<w...@o...pl> wrote:

>Mariusz Kruk wrote:
>
>> Czy ja gdzieś pisałem, że nigdy nie należy optymalizować? Owszem, jeśli
>> ktoś wszystko sortuje bąbelkowo, bo inaczej nie umie i nie jest w stanie
>> zrozumieć, że można inaczej, zapewnie w życiu nie napisze kawałka
>> dobrego kodu. Tego oczywiście nie neguję. Ale już zastanawianie się nad
>> kolejnością porównań żeby zyskać kilka procent szybkości przy sortowaniu
>> kosztem zaciemnienia kodu będzie miało sens tylko w pewnych konkretnych
>> przypadkach.
>
>Akurat sortowanie nie jest chyba dobrym przykładem, bo mało kto rezygnuje ze
>skorzystania z funkcji bibliotecznej. Zwykle te niewydajne rozwiązania
>powstają dla mniej książkowych problemów.
>
>>>To że często nie opłaca się walczyć o 20% wydajności to się zgadzam.
>>
>> Ano właśnie.
>
>I tu jest właśnie ciekawostka... Rzeczywistość pokazuje nam oprócz programów
>szybkich, oraz niezłych ale nie optymalizowanych intensywnie (czyli
>wolniejszych o np. kilkadziesiąt procent), także wiele programów
>beznadziejnie powolnych. Natomiast przy okazji prawie każdej dyskusji na
>temat praktyki robienia powolnych programów ich obrońcy mówią o 1-5-10-15% o
>które nie warto walczyć.
>Jakby podyskutować na temat wydajności takiej np. Javy z jakimś jej
>miłośnikiem, też zazwyczaj zacznie wywody o tanim sprzęcie i o tym że nie
>opłaca się walczyć o każdy procent wydajności - gdy tymczasem każdy nie-
>zaślepiony miłością do tego języka widzi, że w rzeczywistych programach
>różnice wydajności są kilkukrotne, a nie rzędu pojedynczych procentów.

Roznice miedzy czym a czym?... I dlaczego?

kazdy program powinien byc optymalizowany, bo nei ma powodow zby byl
wolny gdy moze byc szybki. Ale przypomneic nelazy stare prawa
Kernighana:

1. Make it working, make it nice later. Czyli ze nie nalezy zbyt wiele
uwagi posiecac optymalizacji na samym poczatku pracy - z wyjatkiem
pzremyslanych decyzji na temat wlasciwych algorytmow i struktur
danych. Liniowe ppzreszukiwania w tablicy zawierajacej milion liczb
jest OK jezeli sie to robi tylko raz, nei jest OK jezeli sie robi
tysiace razy

2. 20% kodu pochlaniania 80% czasu. Trzeba tylko te 20% znalezc,
zoptymalizowac i znalezc nastepne 20% (prawo 80/20). I tak w kolko.
Knuth nawet twierdzi (twierdzil) ze to jest 5/95

Innymi slowy, optymalizacja musi sie odbywac wedle pewnej strategii.

Moje obserwacja mlodych "pistoletow" programistycznych oraz
przesluchiwanie ic hna interview pokazuja ze nei maja oni pojecia o
zlozonosci obliczeniowej algorytmow, sprawnosci i optymalizacji
programow. Nei spotkalem jeszcze faceta z dyplomem M. Sc. ktory by
wiedzial jak "w srodku" dziala Javova HashTable, po co jest "load
factor" i po co jest mozliwosc definiowania poczatkowego rozmiaru
hashtable, i jak owe czynniki wplywaja na sprawnosc. W ogole nikt nei
widzial (jak do dzis) jaka jest zlozonosc operracji wyszukiwania w
hashtable i od czego ona zalezy. Jak rowniez jaki jest koszt
zdefiniowania HashTable z domyslnymi wartosciami. Zeby wymienic tylko
jeden problem.

Takich rzeczy sie na studiach nei uczy.

Robi sie wiec bez zastanowienia rozne idiotyzmy dzieki ktorym programy
sa szybkie jak mucha w miodzie. No, ale zawsze mozna wziac szybszy
procesor.

Bylo tu pare slow o "code review". Code review jest miedzy innymi po
to zeby zobaczyc idiotyzmy ktore "pistolety" robia w sensie
sprawnosci.

A.L.