Athlon 12% sneller met optimized gcc compiler flags

Een lezer van Ace's Hardware wist een rijtje met Athlon-optimized flags voor de gcc compiler bijeen te vogelen. Volgens de eerste bevindingen van Johan de Gelas / Ace's Hardware kan de Linux performance van de Athlon hiermee met 12% verbeterd worden:

CFLAGS = -s -static -O3 -fomit-frame-pointer -Wall -mpentiumpro
-march=pentiu mpro -malign-functions=4 -funroll-loops
-fexpensive-optimizations -malign-double -fschedule-insns2
-mwide-multiply

Reacties (65)

[warp]

Breezke:
Je hoeft helemaal geen regeltje aan te passen, doe gewoon "CFLAGS=s -static -O3 -fomit-frame-pointer -Wall -mpentiumpo ./configure" op de commandline en het wordt vanzelf in je Makefile gemept

Michael:
Deze optimalizaties gelden ook voor de Pentium, er is niets Athlons specifieks aan.

Otis:
1) GCC* is geen boutcompiler, tenzij je er niet mee om kan gaan. In plaats van te klagen over GCC, schrijf liever een betere;
2) Een compiler != IDE, als je per se een grafische IDE wilt -> er zijn er zat te vinden, zoek maar even op Freshmeat ofzo;

[Verwijderd]

GCC is zeker geen boutcompiler. GCC ondersteund wel ff wat meer van de C++ standaard dan bijvoorbeeld Visual C++. Bijvoorbeeld templates worden veel beter ondersteund. En betere optimalisaties voor _heel veel_ verschillende processoren.


GCC is trouwens niet alleen C++, GCC staat nog altijd voor GNU Compiler Collection en _niet_ voor GNU C Compiler (zo heette ut eerst).

[Verwijderd]

Hmm.... Ik werk veel met de GNU C compiler, en ik wil hier even wat commentaar op geven, per flag dus.

-s -static: Twee flags die hetzelfde doen, en ervoor zorgen dat je binary een orde van grootte meer ruimte inneemt, omdat alle libaries meegelinkt worden. Dat het hier sneller door wordt is alleen te merken bij het opstarten van het programma. Deze parameter WIL JE DUS NIET GEBRUIKEN, tenzij je een programma zonder source code wil distribueren en zeker wilt weten dat mensen niet met de verkeerde libaries rondsnuffelen.

-O3 - Maakt je programma exact 0% sneller dan -O2 en is wel dertig keer buggier. Er is wel verschil tussen -O2 en -O, maar zelfs dat is zo klein dat de kans dat gcc foute code produceert het performance verschil onbelangrijk maakt. En geloof me nou maar, die kans is er echt, ik ben er zelf al een aantal keer (HARD!) tegenaan gelopen.

-fomit-frame-pointer: Geen probleem, nuttige flag in sommige gevallen (veel rekenwerk, veel functies ofzo).

-mpentiumpro, -march=pentiumpro: De laatste parameter voldoet, die impliceert namelijk de eerste De nadelen hiervan zijn natuurlijk duidelijk: Je software draait niet meer op oude bakken. Verder haal je hier natuurlijk best wel wat performancewinst uit.

-funroll-loops: Tsja, dit kan nuttig zijn als je veel rekenwerk doet in je progje. Neemt wel meer harddisk/geheugenruimte in.

-malign-functions, -fschedule-insns2, -mwide-multiply: Nuttige flags. Behoorlijk CPU-specifiek, dus dit zal je programma behoorlijk trager maken op niet-Athlon/P-3 systemen.

-malign-double: Deze flag wil je NIET gebruiken, tenzij je veeeeel gebruik maakt van doubles in je programma. Dit zorgt ervoor dat de stack niet met 4 maar met 8 bytes tegelijk wordt gebruikt. Als je vervolgens integers gaat gebruiken, neemt elke integer 2 stackplaatsen in! Ik neem aan dat het testprogramma dit doet, anders wil je niet aan deze flag komen.

-Wall: Deze flag zou ieder programma moeten gebruiken, en heeft niets met optimalisatie te maken, maar alles met goede code. Dit zorgt ervoor dat GCC over alles warnings begint te spuien.

-fexpensive-optimizations heeft bijna geen nut, maar omdat we het hier over Athlons hebben gaan we niet zeiken over het feit dat je source er langer over doet om te compilen

We voegen hier nog een flagje aan toe:

-pipe: Zorgt voor een snellere compile omdat niet een tussenbestand, maar een pipe wordt gebruikt voor de communicatie tussen de assembler, preprocessor en compiler.

Zo, en aldus houden we over:

CFLAGS = -Wall -O2 -pipe -fomit-frame-pointer -march=pentiumpro -malign-functions=4 -funroll-loops -fexpensive-optimizations -malign-double -fschedule-insns2 -mwide-multiply

En zo denk ik erover. En bedenk altijd maar, het is beter om je source te optimaliseren dan erop te vertrouwen dat de compiler het voor je doet.

[Lizard]

Breezke

Je hoeft niet steeds je makefile aan te passen,
die extra compiler flags kan je ook in een environment variabele zetten (CFLAGS zo uit m'n hoofd)

Dus 't tweaken wordt zo wel makkelijker

[Jit]

Go Havoc

En als kleine aanvulling voor een ieder die andere compilers 'leuker' vinden.... werken die op net zoveel platformen als GCC? Dat is nl. een belangrijke reden waarom een heleboel mensen gcc gebruiken, het ondersteund bijna willekeurig welke chip die je gebruikt en dat is soms belangrijker dan de paar procent extra performance die je er uit kan halen door wat chip-specifieke optimalisaties uit te voeren. Neemt niet weg dat het toevoegen van deze optimalisaties voor de meest gebuikte chips niet nuttig zou kunnen zijn...

En inderdaad, GCC is tegenwoorde niet alleen meer de compiler voor C/C++, maar ook voor ADA, Pascal, Fortran, en nog wat vage dingen geloof ik. Wordt dan vanuit die taal omgezet in C of C++ en dan pas echt gecompileerd; volgens m'n docent Compilerdesign een redelijk veel toegepaste methode omdat er op bijna elk platform wel een C-compiler is te vinden.... die van GNU

[EfBe]

Het aloude geleuter dat VC++ minder van de standaard C++ zou ondersteunen is toch dacht ik wel voldoende ontkracht: check uit flag /Za (disable language extensions). et voila. VC++ optimaliseert al beter dan gcc, maar als je echt goede optimalisatie wilt gebruik je gewoon de intel C++ compiler. Ik zie niet in waarom gnu dan ineens voorop loopt.

Verder is het leuk dat gcc op veel platforms beschikbaar is, maar dat is een overbodige opmerking. Elk platform heeft een C compiler (Hell, zelfs de C64!) en veelal (altijd eigenlijk) zijn de native compilers van de platformleverancier beter dan de gcc compiler.

warp: en daarom vind ik gcc een nul-optie. dat de compiler open source is is aardig, maar ik zie niet in waarom iemand hem gaat gebruiken die professionele software distribueert. Maar goed, argumenten als 'schrijf liever een betere', daarmee komen we er wel natuurlijk.

basb: bijna iedere compiler optimaliseert voor de grootste gemene deler van processoren (p5-p6 cores plus amd cores), zodat je zeker weet dat je programma ook opstart.

Anyway: happy makefile hacking.

[servies]

Euh, Otis het blijkt weer 'ns dat je weer nergens wat vanaf weet, zou je in zo'n geval in het vervolg je nutteloze geneuzel voor je willen houden... Je stelt me zwaar teleur, ik had meer verwacht van iemand die een universitaire opleiding heeft gehad, of zou het dan toch waar zijn wat ik toen ooit van iemand van de UT hoorde toen ik daar afstudeerde als HIO-student: "Ah HIO, dan krijgen we ook nog eens wat werkends te zien..."
Ik heb nog nooit van VC++ gehoord voor HPUX of wat voor ander platform dan ook... Als je echt cross-platform wilt ontwikkelen (goh wat is dat toch he Otis, dat ken jij niet he?) dan kom je bijna altijd bij compilers als gcc uit...
Ik zal je nog een klein voorbeeldje geven uit m'n studietijd, we moesten toen een backtracking probleempje uitprogrammeren en daar was de code gegenereerd door gcc maar liefst 4x sneller dan de code gegenereerd door de c-compiler van Microsoft of de Borland compiler. Dat VC++ code voor windows beter optimaliseert snap ik best wel, het probleem is alleen dat de sources ook alleen maar bruikbaar zijn voor Windows en nergens anders voor.
Een ding is zeker, wanneer VC++ allang is vergeten bestaat GCC waarschijnlijk nog steeds.

[Verwijderd]

Claimen dat Otis anti-Unix is, is tot daaraantoe, maar wat jullie allemaal als argumenten *voor* cross platform gebruiken is niet veel beter.

</div><div class=b4>Misschien kan MS zijn software ook wel even opnieuw compileren zodat het sneller loopt op een Athlon (of Pentium), maar ja, dat weet je niet omdat je de source niet te zien krijgt.</div><div class=b1>

Waar slaat dit in godsnaam op? Waar gaat dit over, over het opnieuw compileren van de compiler zelf, of over het compileren van MS software zodat het sneller gaat? Waarom zou je je compiler opnieuw willen compileren, opdat het misschien 12 % sneller gaat op een Athlon en er toch heel veel mensen met !Athlon computers zijn die die snelheidswinst niet merken?
Volgens mij heeft die persoon een beetje een probleem met het niet open-source zijn van Windows. Nou jong, ik zou maar blij zijn dat dat niet opensource is, want je zou je dood lachen.


</div><div class=b4>En inderdaad, GCC is tegenwoorde niet alleen meer de compiler voor C/C++, maar ook voor ADA, Pascal, Fortran, en nog wat vage dingen geloof ik.</div><div class=b1>

En wat hebben wij daaraan? Is daarom gcc een betere C++ compiler dan Microsoft Visual C++?

Beetje zinniger argumenten please.

[EfBe]

Zoooooooo zeg. Ene servaas post een zeer beledigende persoonlijke flame, en krijgt +1 interessant.

Voor Servaas Te B.: 1) jij hebt echt het recht niet me zo te beledigen, ik heb nl zelf hio gedaan (Dezelfde als jij, ik sta 2 personen boven jou (FB) op de oud studenten page van hio.hen.nl) en zal zeker niet een bekrompen mening hebben over hio-ers plus dat de mening over hio-ers echt niets met het hele verhaal te maken heeft. 2) ik snap meer dan jij denkt, trust me. Het lullige is alleen dat de karavaan zealots meteen op de barricaden springt zodra IEMAND iets negatiefs zegt over Gnu tools of Linux verwante TROEP.

Egcs is nog steeds een aparte compiler voor bv OS/390. Hoezo gemerged? O... Red hat heeft cygnus opgekocht en DUS... aja...

Platform onafhankelijk programmeren heeft niets met je compiler van doen maar met je code. Je kunt platform onafhankelijke C++ code schrijven die op elk platform's native compiler compileert, no gnu needed. Maar ach... wat weet IK daar toch van... als microsoftie, toch?

Havoc: C++ is helemaal geen 'uitbreiding' op C. C++ heeft veel C elementen in zich maar een Pure C++ compiler compileert geen C code om de doodeenvoudige reden dat Stroustrup verschillende C elementen heeft verbannen (#include *.h zonder namespaces, compiler preprocessor directives, enums)
----
<RANT>
Maar ach.. LinSuX RuLeZ... of niet?
</RANT>

Bleh.. wel jammer, nu haal ik nooit de #1 positie op de karma lijst. ah well.. it was fun

[servies]

Ik ben het in zoverre met een aantal mensen eens (wat optimalisaties en gebruikersvriendelijkheid betreft) dat die optimalisaties makkelijker gezet zouden kunnen worden, alleen de -marchXXX vlag zou eigenlijk genoeg moeten zijn. Maar er zijn hier ook een inderdaad een aantal mensen die een IDE verwarren met een compiler. Ik werk zelf niet met VC++, maar ik vermoedt dat de compiler die onder water wordt aangeroepen net zo'n lijst aan opties meekrijgt als GCC. Het nadeel voor GCC is alleen dat de gemiddelde persoon die er mee werkt ze met de hand moet invoeren en in een IDE gebeurt dit door een "optimalisatie" optie te selecteren.
Dat die optimalisaties niet automatisch gebeuren bij GCC is waarschijnlijk een gevolg van het feit dat het op meerdere platformen draait. Ik heb een vermoeden dat het wereldrecord 'ondersteunde platforms' wel bij GCC zal liggen.
Verder is het natuurlijk onzin om Windows zelf te gaan optimaliseren voor specifieke intel(-compatible) processoren, koop je een nieuwe computer moet je ook een nieuwe versie van Windows kopen... Dat doet Red Hat bijvoorbeeld ook niet. De Red Hat 6.2 (intel editie) draait op alles van een 386 tot een AMD Athlon met dezelfde binaries. Dat je het eventueel via de sources zou kunnen optimaliseren voor je eigen CPU is een ander verhaal.

Euhh, Otis... Je moet je iets minder op je teentjes getrapt gaan voelen hoor, want ik lees er eigenlijk niet zo heel veel in... Of misschien ben ik al wel wat geharder in het leven...

Verder is C++ wel degelijk een uitbreiding op C, de naam zegt eigenlijk al genoeg.

<oftopic>
Verder is het natuurlijk compleet idioot dat je hier zit te posten om een bepaalde ranking qua karma te halen... Als je alleen maar zit te posten om daar de eerste plaats te halen moet dat systeem eigenlijk maar weer afgeschaft worden...
</oftopic>