<f...@g...pl> napisał(a):

> kcalkiem niedawno przyspieszylem jedna gierke okolo 2 razy
> (ramka spadla z 30 ms do ok 15 ms) przez zamienienie czterech
> intow na floaty (czy cos takiego bo nei pamietam byc moze
> dokladnie) - staranne traktowanie procka mysle moze miec jednak
> sens i gdyby np okazywalo sie ze przy umiejetnosci poprawiania
> kodu i popopoprawianiu paru procedur w asmie program dzialal
> dwa razy plynniej to warto sie uzyc i uzywac asma

Niezbyt czesto musze martwic sie wydajnoscia implementacji, z
rzadka mi sie zdarza. Wtedy najczesciej obserwuje takie
problemy:
1) brak zrownoleglenia (jesli mozna to podciagnac pod implementacje)
2) brak optymalizacj cache
3) w wiekszych programach zla struktura danych, zbyt duze straty na konwersje

Ostatnio wzialem pod lupe pewien programik do generowania lasow drzew
regresyjnych. Program jest napisany bardzo intuicyjnie, np. kazdy
rekord z pliku jest alokowany przez new i sa listy rekordow (a nie tablice
liniowe). Program uzywa (chyba) dobrego algorytmu ale ma kiepska
implementacje. Nie ma zoptymalizowanej pamieci cache i nie jest
zrownoleglony ani nie ma jednej globalnej struktury danych przyjaznej
dla wszystkich procedur, tylko robi konwersje.

No wiec zaczalem go przyspieszac. Zadnego z przyspieszen nie dokonczylem,
co bylem bliski ukonczenia, to wpadalem na jeszcze jedno udoskonalenie :D

Jednak z wstpenych pomiarow czasow wykonania podprocedur moge juz oszacowac
ze wersja finalna przyspieszy 200 razy (slownie dwiescie), czyli okolo 40
razy jakby nie liczyc zrownoleglenia. Obie wersje programu sa napisane w
proceduralnym C++.

Wiec mam ta sama watpliwosc co Bartek: czy trzeba uzywac asemblera zeby
przyspieszac programy? Bym zyskal przyspieszenie 400 razy w asemblerze?

Pozdrawiam!






--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/