On 26 Sty, 02:12, Mariusz Marszałkowski <m...@g...com> wrote:

> To jeszcze nic... Wlasnie obserwuje jak na innym programie,
> jak po dodaniu statycznej tablicy do ktorej nie ma jeszcze
> zadnego odwolania w kodzie, program z 300sekund spowolnil
> do 358s :) Inaczej rozlozone dane i juz taki spadek wydajnosci. I
> co mam na  to poradzic?

Kontrolowac wyrównanie?

> Ok, mowie tak na zas ze kompilacja GCC nie jest trywialna :)

Ale nie jest to tez wiedza tajemna. Chyba.


> Podobnie jest opcja w ktorej podaje sie ilosc pamieci
> cache. Moze ktos lepiej poslugujacy sie GCC czyta
> ten watek i nam troche opowie o mozliwosciach GCC?


Mam g++ 4.4.cos, chyba 0 z qtcreatora. Niestety, nadal mimo
roznych opcji, w tym floop-unroling i podobnych daja jakies 20%
gorsze wyniki niz VC (z duza iloscia opcji, ale nic wymyslnego,
/fp:precise, co ciekawe, 'fast' pogarsza wyniki).

Jakies pomysly na magiczne opcje dla gcc?

pozdrawiam
bartekltg

do góry

On 29 Sty, 17:24, bartekltg <b...@g...com> wrote:
> On 26 Sty, 02:12, Mariusz Marszałkowski <m...@g...com> wrote:
>
> > To jeszcze nic... Wlasnie obserwuje jak na innym programie,
> > jak po dodaniu statycznej tablicy do ktorej nie ma jeszcze
> > zadnego odwolania w kodzie, program z 300sekund spowolnil
> > do 358s :) Inaczej rozlozone dane i juz taki spadek wydajnosci. I
> > co mam na  to poradzic?
>
> Kontrolowac wyrównanie?
Na co dzien mierze czasu roznych wersji programu. Czasami
po innej kolejnosci wcielania naglowkow kod jest 20% szybszy/
wolniejszy :)


> > Ok, mowie tak na zas ze kompilacja GCC nie jest trywialna :)
>
> Ale nie jest to tez wiedza tajemna. Chyba.
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 :)

>
> > Podobnie jest opcja w ktorej podaje sie ilosc pamieci
> > cache. Moze ktos lepiej poslugujacy sie GCC czyta
> > ten watek i nam troche opowie o mozliwosciach GCC?
>
> Mam g++ 4.4.cos, chyba 0 z qtcreatora. Niestety, nadal mimo
> roznych opcji, w tym floop-unroling i podobnych daja jakies 20%
> gorsze wyniki niz VC (z duza iloscia opcji, ale nic wymyslnego,
> /fp:precise, co ciekawe, 'fast' pogarsza wyniki).
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#Optimize-Options

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

Pozdrawiam

do góry

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

do góry

On 30 Sty, 14:51, bartekltg <b...@g...com> wrote:
> On 30 Sty, 06:33, Mariusz Marszałkowski <m...@g...com> wrote:
> pozdrawiam i koncze (chyba sie na razie temat wyczerpal)
> bartekltg

Temat jest ciekawy, ale niestety musze optymalizowac inny kod :/

Pozdrawiam rowniez

do góry