On 30 Sty, 06:33, Mariusz Marszałkowski <m...@g...com> wrote:

> Na co dzien mierze czasu roznych wersji programu. Czasami
> po innej kolejnosci wcielania naglowkow kod jest 20% szybszy/
> wolniejszy :)

Czary.
:)

> Tajemna nie, ale uzytkownik kompilatora musialby wiedziec
> naprawde bardzo duzo, aby przewidzec ze kod dodatkowo
> obciazony pomiarem czasu (tym dla profilera) zadziala
> szybciej. Bez tej wiedzy trzeba sprawdzic milion kombinacji
> opcji i wybrac najszybsza :)

Zawsze wydawalo mi sie, ze to ma wiedziec kompilator.
Czlowiek ma mu jedynie sugerowac, dawac wskazowki
-f_optymalizuj_ile_sie_da -fwole_kod-szybszy_niz_mniejszy(*).
-f_nie_zalezy_mi_na_czasie_kompilacji_rob_dowolne_sz
tuczki

Z, tym, ze przy (*) ine ma to byc naiwne rozwijanie czego sie da,
kompilator powinien tez wiedziec, ze nieraz kod mniejszy bedzie
szybszy.

> Ciekawe, w moich pomiarach rzadko VC wygrywa. Ale raz
> widzialem jak VC wygenerowal kod az dwa razy szybszy.

> > Jakies pomysly na magiczne opcje dla gcc?
>
> Raczej nie pomoge, osobiscie uzywam go tylko w
> najprostszy sposob:
> g++ -O3 -march=native -mtune=native -fomit-frame-poionter -fprofile-
> generate[use] *.cpp

> Pod poniższym linkiem jest 50 stron o opcjach optymalizacji :)
>
> http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Optimize
-Options.html#Opt...

50 stron. Zeby dosignac wersje z wylikanymi opacjami:)

Prawde mowiac, budujac konkretne programy pewnie siega sie
po cos w rodzaju intelowskiego kompilatora cpp ktory bedzie
jeszcze szybszy.

> Przy mnozeniu macierzy najbardziej ciekawia mnie opcje:
> -floop-block
> l1-cache-size

Na oko robi to to, co my zrobilismy recznie.
Moze robi to lepiej, trzeba bedzie kiedys sprawdzic.

pozdrawiam i koncze (chyba sie na razie temat wyczerpal)
bartekltg