Marteno Rodia pisze:
> Góglałem, ale nie udało mi się znaleźć syntetycznej odpowiedzi na
> pytanie. Interesuje mnie, jak należy pisać program, żeby wykonywał się
> on szybko. Z reguły pisuję w Javie, teraz mam napisać program (a
> właściwie część do większego programu) w C++, który wykonuje pewne
> obliczenia potrzebne do kompresji wideo. Będzie dużo danych i dużo
> liczenia.
>
> Ogólnie wiem, że:
>
> 1) dużo czasu zjadają np. operacje wejścia/wyjścia
> 2) w miarę możliwości warto przydzielać pamięć statycznie, a nie
> dynamicznie
Nie należy 'zbyt często' dynamicznie (w małych kawałkach). Obawiam sie
że tak wielkich danych nie obsłużysz statycznie. Optymalizacja pamięci
czasem jest zbieżna z opt.szybkości, czasem przeciwstawna.
> 3) unikać nadmiaru rzeczy wykonywanych w pętli (np. sprawdzanie
> jakichś warunków) - innymi słowy:
> 4) tak przebudować algorytm, żeby zrobić to samo wykonując mniejszą
> ilość operacji.
>
> Pytania:
> 1) Czy mam rację?
Częściowo
> 2) Co jeszcze o czym nie wiem?
Tak
0) Że program ma być najpierw dobry, potem zoptymalizowany. Jak
zaczniesz amatorsko optymalizować, możesz źle skończyć.
a) Że kompilator potrafi bardzo dużo zoptymalizować tylko wystarczy mu
nie przeszkadzać. Najczęściej w wyrażeniem w pętli sobie poradzi (nawet
lepiej od człowieka)
b) że algorytm wyższy intelektualnie (z mocnym zapleczem
teoretyczno-matematycznym, bardziej przemyślany) może być o rzędy
wielkości szybszy od amatorskiego. I temu nie dorównają wyłączania przed
pętlę itd. Na video się nie znam, ale porównaj (studencki przykład)
sortowania od naiwnego do profesjonalnego. Na słowo 'kompresja' jestem
pewien, że algorytm naiwny będzie 100x wolniejszy.
c) właściwości procesora (cache 1i2, sprzętowa optymalizacja pewnych
operacji/typów, konwersje, położenie w pamięci) aż do wykorzystania
okazji do zrównolegleń we współczesnych zabawkach

W konkluzji:
I) nie optymalizować.
II) czytać dobre książki z jednej strony z branży, z drugiej o CPU i
kompilatorach optymalizujących

Nawiasem mówiąc w świecie Javy też powinieneś się spotkać z zaleceniami,
po części o algorytmach, po drugie o nie przeszkadzaniu JVM.