Forskjell på 386- og686 Kernel

[zyp]

Siterer meg selv: «Optimering er oppskrytt.»

Det er noe ytelse å hente på å optimere for en bestemt cpu, avhengig av applikasjon, men ikke en voldsom økning.

 

Jeg ser på blodoptimering (slik enkelte Gentoo-folk driver med) som en hobby, på lik linje med overklokking, der man leker med ting, for en liten ytelsesøkning.

 

Nå skal det nevnes at jeg selv bruker Gentoo, men ikke på grunn av optimering. Jeg liker fleksibiliteten og strukturen (og jeg vet at det finnes andre distribusjoner som ligner, men jeg er fornøyd med Gentoo ).

[drall]

Nå prater ikke jeg om en vanlig gentoo install, men om en gentoo 2005.0 stage 1/3 NTPL installasjon (med CFLAG'sene "-O3 -march=pentium4 -fomit-frame-pointer -pipe -ftracer -fforce-addr -momit-leaf-frame-pointer", udev, og hele pakka).

NPTL er inkludert i de fleste distroer (nå også i slackware fom et par dager siden).

 

-O3 er ofte treigere enn -O2, først og fremst fordi den inliner funksjoner brutalt uten å ta hensyn til hintene gitt av utvikleren. I tillegg gjør den av samme grunn binærfilene større og mer minnesugne, og kan føre til at ting ikke vil passe inn i cachen. Gjett hvorfor utviklerne av linux-kernelen bannlyser denne?

-momit-leaf-frame-pointer inngår i -fomit-frame-pointer.

-ftracer og -fforce-addr er ikke del av -O3 med den grunnen at de vanligvis ikke gjør ting bedre.

-march=pentium4 ser ut til å gjøre ting raskere like ofte som den gjør ting treigere, og har tilsynelatende aldri stor innvirkning.

-pipe sørger bare for at ting kompilerer raskere.

Gode CFLAGs varierer fullstendig fra kildekode til kildekode.

 

Om du absolutt skal kompilere ville jeg heller ha satset på fvisibility-flaggene, LDFLAGS="--Wl,-O1", eller andre ting som muligens kan få ting til å laste ørlite grann raskere. Det vil du sannsynligvis merke mer av, avhengig av hvor mye du tror .

 

Snart begynner jeg å henvise folk til funroll-loops.org

Endret 17. mai 2005 av drall

[Øyst]

jeg tror (er sikker på) at gentooen min til daglig er en del kjappere enn slackwaren din.

Dette er dessverre noe vi ikke kan bevise eller motbevise.

Min er faring er at march kompilering mot en spesifikk arkitektur har lite for seg. Jeg har flere ganger kjørt Gentoo-systemer som er blodig optimert, og mener at det allikvel ikke overgår responsen i Slackware

[olear]

Min er faring er at march kompilering mot en spesifikk arkitektur har lite for seg. Jeg har flere ganger kjørt Gentoo-systemer som er blodig optimert, og mener at det allikvel ikke overgår responsen i Slackware

[phatsam]

For min del, så har jeg 2 desktop maskiner og har faktisk tid til å drive på med optimalisering (eller hva dere mener jeg driver med).

 

Jeg merker i hvert fall STOR forskjell på en gentoo stage2 install og denne stage 1/3 NTPL installen (som har en diverse tåpelige cflags m.m).

Endret 17. mai 2005 av phatsam

[Del]

GCC er nok en av de beste kompilator-samlingene som eksisterer. Det jeg prøver å poengtere er at å kompilere selv som regel har lite for seg, spesielt mht å optimalisere til spesifikk prosessor.

 

Jeg er forøvrig uenig i at det ofte er lite å vinne fra -O1 til -O2 (i cpu-begrensede programmer).

 

Du har ikke vært borti pathscale antar jeg, det er en grunn til at alle benchmarks (fra leverandører) som sendes inn til spec.org bruker den kompilatorpakken.

 

Når det gjelder O1 og O2 kan det hende vi snakker forbi hverandre siden vi bruker veldig upresise uttrykk (lite/ofte). Med lite mener jeg under 20%, med ofte mener jeg ikke som regel, men jeg har i grunnen ikke noe prosent tall å komme med der. At optimaliseringer (utover O1) kan gi betydelig gevinst i mange tilfeller er jeg helt enig i. Legger ved en liten link til noen enkle benchmarks kun for eksempelets skyld (ikke ment som et veldig tungtveiende argument):

http://www.coyotegulch.com/products/acovea...a_original.html

[kyrsjo]

Ang GCC og cmov: Så vidt jeg vet, er det største problemet at mange distroer (Fedora i alle fall) nekter å bruke cmov, da den ikke er støttet på alle "586" cpu'er...

[drall]

GCC skal optimalt sett bruke cmov-instruksjonen dersom -march>=i686 er spesifisert, ettersom cmov-opcoden er en del av i686-arkitekturen. Det virker likevel som om det er begrenset hvor mye gcc klarer å ta i bruk instruksjonen. Jeg antar den i det minste greier å oversette ternary-operatoren til cmov.

En titt på asm outputen ville selvsagt gitt svaret på dette.

 

EDIT: I begge disse veldig enkle eksemplene klarte gcc-3.4 å ta i bruk cmov-instruksjonen, og gav identisk output som den burde.

int main() {
       int a=0, b=1;
       int i=&a>&b?a:b;
       return i;
}

int main() {
       int a=0, b=1, i;
       if(&a>&b) i=a;
       else i=b;
       return i;
}

(Ja, jeg er klar over at jeg sammenligner adresser. Å sammenligne verdi ville ha vært enkelt å optimalisere bort.)

Endret 19. mai 2005 av drall