Binaire bestanden optimaliseren in C/C++ met GCC en Clang

Wanneer je begint te spelen met de compilatieopties in C en C++ Het is verleidelijk om alle "coole" opties die je online ziet in te schakelen. Maar in werkelijkheid kan een verkeerde combinatie van parameters je systeem instabiel maken, builds laten mislukken, of erger nog, binaire bestanden genereren die op subtiele manieren falen of waarvoor informatie-extractie nodig is; in die gevallen kan het nuttig zijn. verborgen tekst in binaire bestanden extraheren onderzoeken.

Het doel van deze handleiding is om u op een praktische en eenvoudige manier te laten begrijpen hoe Binaire bestanden optimaliseren in C/C++ met GCC en Clang de juiste opties gebruiken: uit de klassieke opties -O2, -march y -pipe...tot geavanceerde technieken zoals LTO, PGO, OpenMP, Graphite en beveiligingsversterking. Je zult ook zien hoe dit alles samenwerkt met CMake, MinGW/MSYS2, Visual Studio, Xcode of Ninja om een ​​draagbare en onderhoudbare omgeving te bouwen.

Wat zijn CFLAGS en CXXFLAGS en hoe gebruik je ze zonder problemen?

In vrijwel alle soorten systemen Unix (Linux(bijv. BSD, enz.) worden de variabelen gebruikt CFLAGS y CXXFLAGS opties doorgeven voor de C- en C++-compiler. Ze maken geen deel uit van een formele standaard, maar ze zijn zo gangbaar dat elk goed geschreven buildsysteem (Make, Autotools, CMake, Meson, enz.) ze respecteert.

In distributies zoals Gentoo worden deze variabelen globaal gedefinieerd in /etc/portage/make.confVan daaruit worden ze overgenomen door alle pakketten die met Portage zijn gecompileerd. Op andere systemen kunt u ze exporteren in de shell of in een... Makefileeen script van CMake of iets dergelijks.

Het is vrij gebruikelijk om te definiëren CXXFLAGS het hergebruiken van de inhoud van CFLAGS En voeg, indien nodig, eventuele specifieke opties voor C++ toe. Bijvoorbeeld: CXXFLAGS="${CFLAGS} -fno-exceptions"Het belangrijkste is om daar niet lukraak vlaggen toe te voegen, want die worden toegepast op alles wat je compileert.

Het is belangrijk om duidelijk te zijn dat Agressieve opties in CFLAGS/CXXFLAGS kunnen builds laten vastlopen.Dit kan leiden tot bugs die erg moeilijk op te sporen zijn of zelfs de prestaties van de binaire bestanden vertragen. Een hoge mate van optimalisatie resulteert niet altijd in betere prestaties, en sommige transformaties kunnen gebruikmaken van aannames waaraan uw code niet voldoet.

Basisoptimalisatie: -march, -mtune en -O-niveaus

De basis van elke verstandige aanpassing bestaat uit drie elementen: Selecteer de CPU-architectuur, kies het optimalisatieniveau en activeer eventueel kleine, onschadelijke verbeteringen. als -pipeBijna al het andere moet later komen, en met een helder hoofd.

Architectuurkeuze: -march, -mtune en bedrijf

De keuze -march=<cpu> Vertelt GCC/Clang welke specifieke processorfamilie gebruikt moet worden. gaat code genererenHet maakt het gebruik van specifieke instructies mogelijk (SSE, AVX, AVX2, AVX-512, enz.) en aanpassingen aan de ABI. Als je te slim bent en een te moderne CPU kiest, zal het binaire bestand simpelweg niet opstarten op oudere machines.

Om erachter te komen wat je processor ondersteunt, kun je in Linux raadplegen... /proc/cpuinfo of gebruik commando's van de stijlcompiler zelf gcc -Q -O2 --help=targetIn moderne x86-64-systemen zijn generieke profielen gestandaardiseerd, zoals x86-64-v2, x86-64-v3 y x86-64-v4welke groep instructiesets uitbreidt en sinds GCC 11 wordt ondersteund.

Plus -march, bestaat -mtune=<cpu> om de planning te "verfijnen". Van code naar een specifiek model zonder nieuwe instructies te gebruiken. Ze komen ook voor in niet-x86-architecturen. -mcpu y -mtune Relevante opties zijn onder andere (ARM, PowerPC, SPARC…). In x86, -mcpu Het is in feite achterhaald.

Een veelgebruikte truc is -march=nativeHierdoor kan de compiler de CPU van de lokale machine detecteren en automatisch de juiste extensies activeren. Dit is ideaal in omgevingen waar je de binaire bestanden alleen uitvoert op dezelfde machine waar je ze compileert, maar het is een valkuil als je pakketten genereert voor andere CPU's.

In recente processors van Intel En AMD en GCC gebruiken specifieke namen voor elke familie, zoals -march=rocketlake, -march=sapphirerapids, -march=znver2 o -march=znver3Deze opties bundelen de geavanceerde instructies (AVX2, AVX-512, FMA, enz.) van elke generatie en stellen u in staat om behoorlijk wat uit de mogelijkheden te halen. hardware wanneer je weet waar je het gaat implementeren.

Optimalisatieniveaus -O: wanneer elk niveau te gebruiken

De keuze -O regelt het algehele optimalisatieniveau toegepast op de code. Elke stap activeert een bredere reeks transformaties, die van invloed zijn op zowel de compilatietijd en het geheugenverbruik als het debuggen.

• -O0Niet geoptimaliseerd. Dit is de standaardoptie als u niets opgeeft. Het compileert snel en genereert code die zeer gemakkelijk te debuggen is, maar het is traag en omvangrijk. Ideaal voor de vroege ontwikkelingsfase en het onderzoeken van complexe bugs.
• -O1Eerste optimalisatieniveau. Past relatief goedkope verbeteringen toe die doorgaans een behoorlijke prestatieverbetering opleveren zonder de compilatie te zwaar te maken.
• -O2Dit is het aanbevolen niveau voor algemeen gebruik in de meeste projecten. Het biedt een goede balans tussen prestaties, compilatietijd en stabiliteit.En daarom is dat de waarde die veel distributies standaard gebruiken.
• -O3: activeert alle optimalisaties van -O2 Agressievere transformaties, zoals zeer sterke lusontwinding of intensievere vectorisatie. Dit kan uitstekend werken in sommige numerieke code, maar het verhoogt ook de kans op ongedefinieerd gedrag in de code of een grotere uitvoerbare bestandsgrootte.
• -OsDeze methode probeert de binaire bestandsgrootte te verkleinen door ruimte boven snelheid te prioriteren. Het is nuttig in omgevingen met opslagruimte of een zeer beperkte cache.
• -Oz (GCC 12+): drijft de besparing op bestandsgrootte tot het uiterste, ten koste van aanzienlijke prestatievermindering. Nuttig voor zeer kleine binaire bestanden of zeer specifieke scenario's.
• -OfastHet is net zoiets als een -O3 Het voldoet niet strikt aan de C/C++-standaarden. Het stelt je in staat om bepaalde taalgaranties te doorbreken om extra prestaties te behalen, met name bij drijvende-komma-berekeningen. Je moet het gebruiken met een volledig begrip van wat je doet.
• -OgOntworpen voor debuggen. Het past alleen optimalisaties toe die de debugger niet te veel hinderen en laat de code in een middenpositie tussen... -O0 y -O1.

Niveaus boven -O3 als -O4 o -O9 Het is allemaal schijn.De compiler accepteert ze, maar behandelt ze intern als -O3Er zit geen verborgen magie in, alleen maar aanstellerij.

Als je merkt dat builds op mysterieuze wijze mislukken, vreemde crashes optreden of dat de resultaten verschillen afhankelijk van de optimizer, is een goede diagnostische stap: tijdelijk naar beneden gaan -O1 of -O0 -g2 -ggdb Om gemakkelijk te debuggen binaire bestanden te verkrijgen en de bug met nuttige informatie te rapporteren.

-pijp en andere basisopties

De vlag -pipe Geeft de compiler de opdracht om pipes in het geheugen te gebruiken. In plaats van tijdelijke bestanden op schijf tussen de compilatiefasen (voorverwerking, compilatie, assemblage). Dit maakt het proces meestal iets sneller, hoewel het meer RAM-geheugen verbruikt. Op machines met zeer weinig geheugen kan het ervoor zorgen dat het systeem vastloopt tijdens het compileren, dus gebruik het in die gevallen spaarzaam.

Andere traditionele opties zoals -fomit-frame-pointer Ze stellen je in staat om het stackpointerregister vrij te geven om meer code te genereren, maar ze maken debuggen met duidelijke backtraces lastiger. Op moderne x86-64-architecturen handelt de compiler dit vrij goed af, en vaak is het zelfs niet nodig om dit handmatig in te stellen.

SIMD-extensies, Graphite en lusvectorisatie

Moderne compilers voor x86-64 schakelen automatisch veel SIMD-instructies in, afhankelijk van de gekozen CPU. -marchDesondanks zie je nog steeds vlaggen zoals -msse2, -mavx2 of vergelijkbare opties die expliciet kunnen worden toegevoegd.

Over het algemeen geldt dat als je gebruikmaakt van een -march Dit is prima; je hoeft het niet handmatig te activeren. -msse, -msse2, -msse3, -mmmx o -m3dnowOmdat ze standaard al zijn ingeschakeld. Het is alleen zinvol om ze af te dwingen op zeer specifieke CPU's waar GCC/Clang ze niet standaard inschakelen.

Voor complexe lussen bevat GCC een reeks optimalisaties. grafietdie afhankelijk zijn van de ISL-bibliotheek. Via vlaggen zoals -ftree-loop-linear, -floop-strip-mine y -floop-block De compiler analyseert lussen en kan deze herstructureren om de datalocaliteit en parallelisatie te verbeteren; zie voor specifieke gevallen voorbeelden van laag-niveau C Het helpt om de code aan te passen aan deze transformaties.

Deze transformaties kunnen goede resultaten opleveren bij complexe numerieke code, maar Ze zijn niet onschadelijk.Ze kunnen het RAM-gebruik tijdens de compilatie aanzienlijk verhogen en crashes veroorzaken in grote projecten die daar niet voor ontworpen zijn. Daarom wordt aangeraden ze alleen in te schakelen in specifieke codefragmenten of projecten waar ze getest en bewezen correct te werken.

Parallellisatie: OpenMP, -fopenmp en -ftree-parallelize-loops

Als uw code gebruikmaakt van OpenmpZowel GCC als Clang bieden vrij solide ondersteuning via deze optie. -fopenmpDit maakt het mogelijk om codefragmenten, met name lussen, te paralleliseren met behulp van instructies in de broncode zelf, en voor de compiler om het werk in meerdere threads te genereren.

Plus -fopenmpGCC bevat de optie -ftree-parallelize-loops=NWaar N Het wordt meestal ingesteld op het aantal beschikbare cores (bijvoorbeeld met behulp van $(nproc) (in buildscripts). Dit probeert lussen automatisch te paralleliseren zonder dat er handmatige instructies hoeven te worden toegevoegd, hoewel het succes sterk afhangt van hoe de code is geschreven.

Je moet dat onthouden Het wereldwijd inschakelen van OpenMP voor een volledig systeem kan zeer problematisch zijn.Sommige projecten zijn er niet op voorbereid, andere gebruiken hun eigen modellen voor gelijktijdigheid, en sommige compileren gewoonweg niet wanneer ze ermee te maken krijgen. -fopenmpHet is verstandig om dit per project of zelfs per module in te schakelen, en niet in de algemene CFLAGS van het systeem.

Linktijdoptimalisatie: LTO

La Linktijdoptimalisatie (LTO) Hierdoor is de compiler niet langer beperkt tot één enkel bronbestand tijdens het optimaliseren, maar kan hij het hele programma in de linkfase bekijken en globale optimalisaties toepassen op alle betrokken objecten.

In de GCC wordt het geactiveerd met -fltoen er kan een aantal threads worden opgegeven, bijvoorbeeld -flto=4, of laat het het aantal kernen detecteren met -flto=autoAls het ook gebruikt wordt -fuse-linker-plugin samen met de verbindingsschakel goud En dankzij de LTO-plugin die in binutils is geïnstalleerd, kan de compiler LTO-informatie extraheren, zelfs uit statische bibliotheken die bij de binding betrokken zijn.

LTO genereert meestal iets kleinere en in veel gevallen snellere uitvoerbare bestandenomdat het dode code elimineert en inlining tussen modules mogelijk maakt. In ruil daarvoor, de tijd De compilatietijden en het geheugenverbruik schieten omhoog, vooral bij grote projecten met duizenden objectbestanden.

In omgevingen zoals Gentoo, waar het hele systeem opnieuw vanuit de broncode wordt gecompileerd, wordt het globaal toepassen van LTO nog steeds als een delicate kwestie beschouwd: Er zijn nog steeds veel pakketten die niet goed werken met LTO. en vereisen dat het selectief wordt uitgeschakeld. Daarom wordt meestal aangeraden om het alleen in te schakelen in specifieke projecten of GCC/Clang-builds waar het voordeel echt merkbaar is.

PGO: Profielgestuurde optimalisatie

La Profielgestuurde optimalisatie (PGO) Het proces bestaat uit het eenmaal compileren van het programma met instrumentatie, het uitvoeren ervan met representatieve workloads om uitvoeringsstatistieken te verzamelen, en vervolgens het opnieuw compileren met behulp van die profielen om de optimizer te sturen.

In GCC is het gebruikelijke proces als volgt: compileer eerst met -fprofile-generateVoer het programma (of de bijbehorende tests) uit om profielgegevens te genereren, en vervolgens compileren met -fprofile-use verwijst naar de map waarin de profielbestanden zijn opgeslagen. Met extra opties zoals -fprofile-correction of door bepaalde meldingen uit te schakelen (-Wno-error=coverage-mismatch) Veelvoorkomende fouten als gevolg van codewijzigingen tussen fasen kunnen worden vermeden; het is bovendien meestal nuttig Monitor de prestaties met eBPF en perf om nauwkeurige profielen te verkrijgen.

Bij een correcte implementatie kan PGO zorgen voor prestatieverbeteringen die veel groter zijn dan alleen het verhogen van het niveau. -OOmdat het beslissingen neemt op basis van gegevens uit de praktijk, en niet op basis van generieke modellen. Het probleem is dat het een omslachtig proces is: het moet bij elke relevante code-update worden herhaald en het is sterk afhankelijk van de representativiteit van het testscenario voor het daadwerkelijke gebruik.

Sommige projecten (waaronder GCC zelf in bepaalde distributies) bieden dit al aan. specifieke vlaggen of scripts Om PGO automatisch te activeren, is het een handige techniek, maar over het algemeen blijft het een methode voor gevorderde gebruikers die bereid zijn tijd in het proces te investeren.

Versterking: op vlaggen gebaseerde beveiliging

Naast snelheid richten veel omgevingen zich op het beveiligen van binaire bestanden tegen kwetsbaarheden, zelfs ten koste van enig prestatieverlies. GCC en moderne linkers bieden een breed scala aan mogelijkheden. verhardingsopties die geactiveerd kunnen worden via CFLAGS/CXXFLAGS en LDFLAGS.

Enkele van de meest voorkomende zijn:

• -D_FORTIFY_SOURCE=2 o =3Voegt extra controles toe aan bepaalde libc-functies om bufferoverloop tijdens de uitvoering te detecteren.
• -D_GLIBCXX_ASSERTIONS: activeert grenscontroles op containers en C++-strings in de STL, waardoor toegang buiten het bereik wordt gedetecteerd.
• -fstack-protector-strongVoegt canaries toe aan de stack om schrijfbewerkingen te detecteren die de stack beschadigen.
• -fstack-clash-protection: beperkt aanvallen die gebaseerd zijn op botsingen tussen de stack en andere geheugenregio's.
• -fcf-protectionVoegt beveiligingen toe tegen controlestromen (bijv. tegen ROP-aanvallen) op architecturen die dit ondersteunen.
• -fpie samen met -Wl,-pieGenereert positioneerbare uitvoerbare bestanden, noodzakelijk voor effectieve ASLR.
• -Wl,-z,relro y -Wl,-z,nowZe beveiligen de relocatietabel en schakelen luie binding uit. Symbolenhet belemmeren van bepaalde aanvalsvectoren.

Bij sommige distributies zijn veel van deze opties al standaard ingeschakeld in de "versterkte" profielen. Handmatig activeren zonder de gevolgen te begrijpen kan leiden tot merkbaar tragere binaire bestanden.Vooral bij grote of zeer geheugenintensieve applicaties is het een redelijke prijs, maar op openbare servers of gevoelige desktops is het meestal acceptabel.

Kies een compiler en ontwikkelomgeving: GCC, Clang, MSVC, MinGW, Xcode…

In de praktijk kies je vaak niet alleen vlaggen, maar ook... Welke compiler en welke complete toolchain ga je gebruiken? op elk platform. GCC en Clang presteren over het algemeen erg vergelijkbaar, en de verschillen zijn vooral merkbaar in de diagnostiek, de compilatietijden of de compatibiliteit met bepaalde extensies.

En Windows Je hebt verschillende mogelijkheden: Visual Studio (MSVC) met hun gereedschapssets v143, v142enz.; of MinGW-w64 door MSYS2 Dit biedt je native Windows GCC en Clang, samen met de benodigde Win32-bibliotheken. MSYS2 wordt beheerd met pacman en biedt MinGW64-omgevingen (gebaseerd op de klassieke MSVCRT) en UCRT64 (met Universal CRT, een modernere variant).

Op macOS is het standaardpad Xcode met clang/clang++, waarbij het kernconcept is dat Basis-SDK (de systeemversie waarvoor het is gecompileerd) en de Implementatiedoel (de minimale macOS-versie waarop je wilt dat je app werkt). Door dit paar correct in te stellen, voorkom je de klassieke ramp van compileren alleen voor de nieuwste systeemversie, waardoor je binaire bestanden niet werken op iets oudere versies.

In Linux is het gebruikelijk om te gebruiken GCC en Make of NinjaMisschien door CMake als metagenerator te gebruiken. Daarnaast bieden distributies zoals Ubuntu de mogelijkheid om meerdere versies van GCC te installeren en deze te selecteren met update-alternatives, net zoals je het in macOS gebruikt. xcode-select om over te stappen van Xcode.

Als je comfortabele debugomgevingen nodig hebt voor projecten die zijn gegenereerd met Make of Ninja (die een enkele configuratie hebben), Eclips CDT y Visual Studio-code Dit zijn twee erg handige opties: CMake kan de benodigde projectbestanden genereren of er direct mee integreren om te configureren, compileren en debuggen.

Draagbaarheid en CMake: dezelfde code, verschillende toolchains

Om een ​​C/C++-project te compileren zonder de code aan te raken op Windows, Linux en macOS, is een goede combinatie van beide vereist. CMake, de beschikbare generators en de verschillende compilersHet idee is dat het bestand CMakeLists.txt Beschrijf het project op een abstracte manier en CMake genereert het juiste projecttype voor elk platform.

Op Windows kun je CMake aanroepen met -G "Visual Studio 17 2022" om een ​​oplossing te produceren met msbuild, of met -G "Ninja" om snellere builds vanaf de console te krijgen. Bovendien, via -T v143, v142enz., u selecteert de Platform Toolset (MSVC-compilerversie) en met -A x64, Win32 o arm64 U kiest de architectuur.

Bij MinGW/MSYS2 is het gebruikelijk om het volgende te gebruiken: -G "MinGW Makefiles" o -G "Ninja" en, via de variabelen CMAKE_C_COMPILER y CMAKE_CXX_COMPILERKies of je GCC of Clang wilt gebruiken. In dit geval worden de configuraties (Debug, Release, enz.) beheerd via -DCMAKE_BUILD_TYPE, aangezien Make en Ninja slechts in één configuratie verkrijgbaar zijn.

Op macOS, -G Xcode Het biedt je een perfect project om te debuggen in de IDE, en je kunt de SDK en de implementatiedoelgroep beheren met variabelen zoals CMAKE_OSX_DEPLOYMENT_TARGETAls je alleen Make of Ninja wilt gebruiken, gebruik je dezelfde generators als in Linux.

Het mooie hiervan is dat je, mits goed opgezet, één codebase en een consistente set vlaggen (soms platformspecifiek) kunt behouden en in elke omgeving kunt compileren zonder constant aan de broncode te hoeven sleutelen. Het is echter belangrijk om het belangrijkste principe te onthouden: Zorg er eerst voor dat het goed werkt, daarna versnellen we het optimalisatieproces..

Gezien alles wat we gezien hebben, is het algemene idee om vast te houden aan... een gematigde maar effectieve combinatie (zoiets) -O2 -march=<cpu adecuada> -pipe plus een redelijke mate van beveiliging) en reserveer het zware geschut —LTO, PGO, Graphite, agressief OpenMP— voor die projecten of modules waar de verbeteringen echt meetbaar zijn en de bijbehorende onderhouds- en debugkosten worden geaccepteerd.