Optimering af binære filer i C/C++ med GCC og Clang

Når du begynder at lege med kompileringsmuligheder i C og C++ Det er nemt at falde for fristelsen til at aktivere alle de "seje" flag, man ser online. Men virkeligheden er, at en dårlig kombination af parametre kan gøre dit system ustabilt, ødelægge builds eller endnu værre, generere binære filer, der fejler på meget subtile måder eller kræver informationsudtrækning; i disse tilfælde kan det være nyttigt. udtræk skjult tekst i binære filer at undersøge.

Formålet med denne guide er, at du på en praktisk og ligetil måde skal forstå, hvordan Optimering af binære filer i C/C++ med GCC og Clang ved hjælp af de korrekte muligheder: fra de klassiske -O2, -march y -pipe...til avancerede teknikker som LTO, PGO, OpenMP, Graphite og sikkerhedshærdning. Du vil også se, hvordan alt dette passer sammen med CMake, MinGW/MSYS2, Visual Studio, Xcode eller Ninja for at opbygge et bærbart og vedligeholdelsesvenligt miljø.

Hvad er CFLAGS og CXXFLAGS, og hvordan bruger man dem uden at ødelægge tingene?

I næsten alle typer systemer Unix (Linux, BSD osv.) bruges variablerne CFLAGS y CXXFLAGS at videregive muligheder til C- og C++-compileren. De er ikke en del af nogen formel standard, men de er så almindelige, at ethvert velskrevet byggesystem (Make, Autotools, CMake, Meson…) respekterer dem.

I distributioner som Gentoo er disse variabler defineret globalt i /etc/portage/make.confDerfra nedarves de af alle pakker, der er kompileret med Portage. På andre systemer kan du eksportere dem i skallen eller placere dem i en... Makefile, har en script fra CMake eller lignende.

Det er ret almindeligt at definere CXXFLAGS genbrug af indholdet af CFLAGS og tilføj om nødvendigt specifikke indstillinger for C++. For eksempel: CXXFLAGS="${CFLAGS} -fno-exceptions"Det vigtige er ikke at tilføje flag uden forskel, fordi de vil blive anvendt på alt, hvad du kompilerer.

Det er vigtigt at være tydelig, at Aggressive muligheder i CFLAGS/CXXFLAGS kan ødelægge buildsDette kan introducere fejl, der er meget vanskelige at debugge, eller endda gøre binærfilerne langsommere. Høje niveauer af optimering resulterer ikke altid i bedre ydeevne, og nogle transformationer kan udnytte antagelser, som din kode ikke opfylder.

Grundlæggende optimering: -march, -mtune og -O niveauer

Grundlaget for enhver fornuftig justering består af tre elementer: Vælg CPU-arkitekturen, vælg optimeringsniveauet, og aktiver nogle gange små, harmløse forbedringer. som -pipeNæsten alt andet burde komme senere, og med et klart hoved.

Valg af arkitektur: -march, -mtune og company

Valget -march=<cpu> fortæller GCC/Clang hvilken specifik processorfamilie vil generere kodeDet tillader brugen af ​​specifikke instruktioner (SSE, AVX, AVX2, AVX-512 osv.) og justeringer af ABI. Hvis du er for klog og vælger en CPU, der er for moderne, vil den binære fil simpelthen ikke starte på ældre maskiner.

For at finde ud af, hvad din processor understøtter, kan du i Linux konsultere /proc/cpuinfo eller brug kommandoer fra selve stilkompilatoren gcc -Q -O2 --help=targetI moderne x86-64-systemer er generiske profiler blevet standardiseret, såsom x86-64-v2, x86-64-v3 y x86-64-v4hvilken gruppe stigende instruktionssæt og har været understøttet siden GCC 11.

Ud over -march, eksisterer -mtune=<cpu> at "finjustere" planlægningen fra kode til en specifik model uden at bruge nye instruktioner. De forekommer også i ikke-x86-arkitekturer -mcpu y -mtune relevante muligheder inkluderer (ARM, PowerPC, SPARC…). I x86, -mcpu Det er faktisk forældet.

Et almindeligt brugt trick er -march=nativeDette gør det muligt for compileren at registrere den lokale maskines CPU og automatisk aktivere de relevante udvidelser. Dette er ideelt i miljøer, hvor du kun kører binære filer på den samme maskine, hvor du kompilerer dem, men det er en dødsfælde, hvis du genererer pakker til andre CPU'er.

I nyere processorer af Intel Og AMD, GCC inkorporerer specifikke navne for hver familie, såsom -march=rocketlake, -march=sapphirerapids, -march=znver2 o -march=znver3Disse muligheder grupperer de avancerede instruktioner (AVX2, AVX-512, FMA osv.) for hver generation og giver dig mulighed for at få en hel del ud af hardware når du ved, hvor du skal indsættes.

Optimeringsniveauer -O: hvornår hvert enkelt skal bruges

Valget -O styrer det overordnede optimeringsniveau anvendt på koden. Hvert trin aktiverer et bredere sæt af transformationer, hvilket påvirker både kompileringstid og hukommelsesforbrug samt nem fejlfinding.

• -O0Ikke-optimeret. Dette er standardindstillingen, hvis du ikke angiver noget. Den kompilerer hurtigt og genererer kode, der er meget nem at fejlsøge, men den er langsom og stor. Ideel til tidlig udvikling og undersøgelse af komplekse fejl.
• -O1Første optimeringsniveau. Anvender relativt billige forbedringer, der normalt giver en anstændig ydeevneforøgelse uden at gøre kompileringen for tung.
• -O2: er det anbefalede niveau til generel brug i de fleste projekter. Det skaber en god balance mellem ydeevne, kompileringstid og stabilitet., og det er derfor, det er den værdi, som mange distributioner bruger som standard.
• -O3: aktiverer alle optimeringer af -O2 Mere aggressive transformationer, såsom meget kraftig loop-afvikling eller mere intens vektorisering. Dette kan fungere godt i noget numerisk kode, men det er også mere sandsynligt, at det afdækker UB i koden eller oppuster den eksekverbare fils størrelse.
• -OsDette forsøger at reducere den binære størrelse ved at prioritere plads frem for hastighed. Det er nyttigt i miljøer med opbevaring eller meget begrænset cache.
• -Oz (GCC 12+): tager størrelsesbesparelser til det ekstreme og accepterer betydelige ydelsesfald. Nyttig til meget små binære filer eller meget specifikke scenarier.
• -OfastDet er ligesom en -O3 Den overholder ikke strengt C/C++-standarderne. Den giver dig mulighed for at bryde visse sproggarantier for at opnå ekstra ydeevne, især i flydende kommaberegninger. Du skal bruge den med fuld forståelse af, hvad du laver.
• -OgDesignet til fejlfinding. Den anvender kun optimeringer, der ikke forstyrrer fejlfindingsprogrammet for meget, og efterlader koden et sted midt imellem -O0 y -O1.

Niveauer over -O3 som -O4 o -O9 De er alle røg og spejleCompileren accepterer dem, men behandler dem internt som -O3Der er ingen skjult magi der, bare posering.

Hvis du begynder at se builds, der på mystisk vis fejler, mærkelige nedbrud eller forskellige resultater afhængigt af optimeringsprogrammet, er et godt diagnostisk trin midlertidigt gå ned til -O1 o incluso -O0 -g2 -ggdb for at hente let fejlfindingsvenlige binære filer og rapportere fejlen med nyttige oplysninger.

-rør og andre grundlæggende muligheder

Flaget -pipe fortæller compileren at bruge pipes i hukommelsen I stedet for midlertidige filer på disken mellem kompileringsfaser (forbehandling, kompilering, assemblering). Det gør normalt processen noget hurtigere, selvom det bruger mere RAM. På maskiner med meget lidt hukommelse kan det få systemet til at crashe compileren, så brug det sparsomt i disse tilfælde.

Andre traditionelle muligheder som f.eks. -fomit-frame-pointer De giver dig mulighed for at frigøre stakpointerregisteret til at generere mere kode, men de gør fejlfinding med rene backtraces vanskeligere. På moderne x86-64-arkitekturer håndterer compileren dette ret godt, og ofte er det ikke engang nødvendigt at indstille det manuelt.

SIMD-udvidelser, grafit og loopvektorisering

Moderne compilere til x86-64 aktiverer automatisk mange SIMD-instruktioner afhængigt af den valgte CPU med -marchAlligevel vil du se flag som -msse2, -mavx2 eller lignende, der kan tilføjes eksplicit.

Generelt, hvis du bruger en -march Dette er passende; du behøver ikke at aktivere det manuelt. -msse, -msse2, -msse3, -mmmx o -m3dnowfordi de allerede er aktiveret som standard. Det giver kun mening at tvinge dem på meget specifikke CPU'er, hvor GCC/Clang ikke aktiverer dem som standard.

For komplekse løkker inkluderer GCC sættet af optimeringer Graphitesom er afhængige af ISL-biblioteket. Gennem flag som f.eks. -ftree-loop-linear, -floop-strip-mine y -floop-block Compileren analyserer løkker og kan omstrukturere dem for at forbedre datalokalitet og parallelisering; for specifikke tilfælde, se eksempler på lavniveau C Det hjælper med at tilpasse koden til disse transformationer.

Disse transformationer kan give gode resultater i tung numerisk kode, men De er ikke harmløseDe kan øge RAM-forbruget betydeligt under kompilering og forårsage nedbrud i store projekter, der ikke er designet med dem i tankerne. Derfor anbefales det kun at aktivere dem i specifikke kodestykker eller projekter, hvor de er blevet testet og bevist at fungere korrekt.

Parallelisme: OpenMP, -fopenmp og -ftree-parallelize-loops

Hvis din kode bruger OpenmpBåde GCC og Clang tilbyder ret solid support gennem muligheden -fopenmpDette gør det muligt at parallelisere sektioner af kode, især løkker, ved hjælp af direktiver i selve kildekoden, og at compileren genererer arbejdet i flere tråde.

Ud over -fopenmpGCC inkluderer muligheden -ftree-parallelize-loops=NHvor N Den er normalt indstillet til antallet af tilgængelige kerner (for eksempel ved hjælp af $(nproc) (i byggescripts). Dette forsøger automatisk at parallelisere løkker uden at skulle tilføje manuelle direktiver, selvom succes i høj grad afhænger af, hvordan koden er skrevet.

Husk på, at Det kan være meget problematisk at aktivere OpenMP globalt på tværs af et helt system.Nogle projekter er ikke forberedte på det, andre bruger deres egne samtidighedsmodeller, og nogle mislykkes simpelthen med at kompilere, når de støder på det. -fopenmpDet fornuftige er at aktivere det pr. projekt eller endda pr. modul, ikke i systemets globale CFLAGS.

Optimering af linktid: LTO

La Optimering af linktid (LTO) Det gør det muligt for compileren ikke at være begrænset til en enkelt kildefil under optimering, men at se hele programmet i linkfasen og anvende globale optimeringer på alle involverede objekter.

I GCC aktiveres den med -fltoog et antal tråde kan specificeres, for eksempel -flto=4, eller lad den registrere antallet af kerner med -flto=autoHvis det også bruges -fuse-linker-plugin sammen med linkeren guld Og med LTO-plugin'et installeret i binutils, kan compileren udtrække LTO-information selv fra statiske biblioteker involveret i bindingen.

LTO genererer normalt noget mindre og i mange tilfælde hurtigere eksekverbare filerfordi det eliminerer død kode og tillader indlejring mellem moduler. Til gengæld, El tiempo Kompileringstider og hukommelsesforbrug stiger voldsomt, især i store projekter med tusindvis af objektfiler.

I miljøer som Gentoo, hvor hele systemet rekompileres fra kildekoden, betragtes det stadig som en delikat sag at anvende LTO globalt: Der er mange pakker, der stadig ikke fungerer godt med LTO. og kræver selektiv deaktivering. Derfor anbefales det normalt kun at aktivere det i specifikke projekter eller GCC/Clang-builds, hvor fordelen virkelig er mærkbar.

PGO: Profilstyret optimering

La Profilstyret optimering (PGO) Det består af at kompilere programmet én gang med instrumentering, køre det med repræsentative arbejdsbelastninger for at indsamle udførelsesstatistik og derefter rekompilere det ved hjælp af disse profiler til at guide optimeringsprogrammet.

I GCC er det typiske flow: først kompilere med -fprofile-generatekør programmet (eller dets tests) for at generere profildata, og kør derefter kompilere med -fprofile-use peger på den mappe, hvor profilfilerne er gemt. Med yderligere muligheder som f.eks. -fprofile-correction eller ved at deaktivere visse notifikationer (-Wno-error=coverage-mismatch) hyppige fejl som følge af kodeændringer mellem faser kan undgås; det er normalt også nyttigt overvåg ydeevne med eBPF og perf for at opnå præcise profiler.

Når PGO implementeres korrekt, kan det give langt større præstationsforbedringer end blot at øge niveauet af -OFordi den træffer beslutninger baseret på virkelige udførelsesdata, ikke generiske modeller. Problemet er, at det er en besværlig proces: den skal gentages ved hver relevant kodeopdatering, og den er i høj grad afhængig af, at testscenariet er repræsentativt for den faktiske brug.

Nogle projekter (herunder GCC selv i visse distributioner) tilbyder allerede specifikke flag eller scripts at aktivere PGO automatisk, men generelt er det stadig en teknik for avancerede brugere, der er villige til at investere tid i processen.

Hærdning: flagbaseret sikkerhed

Ud over hastighed fokuserer mange miljøer på at beskytte binære filer mod sårbarheder, selv på bekostning af et vist ydeevnetab. GCC og moderne linkere tilbyder en god række af hærdningsmuligheder som kan aktiveres fra CFLAGS/CXXFLAGS og LDFLAGS.

Nogle af de mest almindelige lyd:

• -D_FORTIFY_SOURCE=2 o =3tilføjer yderligere kontroller af visse libc-funktioner for at detektere bufferoverløb under kørsel.
• -D_GLIBCXX_ASSERTIONSaktiverer grænsetjek på containere og C++-strenge i STL'en og detekterer adgange uden for rækkevidde.
• -fstack-protector-strongindsætter kanariefugle i stakken for at detektere skrivninger, der beskadiger den.
• -fstack-clash-protection: afbøder angreb baseret på kollisioner mellem stakken og andre hukommelsesregioner.
• -fcf-protectiontilføjer beskyttelse af kontrolflow (f.eks. mod ROP-angreb) på arkitekturer, der understøtter det.
• -fpie sammen med -Wl,-piegenererer positionerbare eksekverbare filer, nødvendige for effektiv ASLR.
• -Wl,-z,relro y -Wl,-z,nowDe hærder flytningstabellen og deaktiverer lazy binding af symbolerhindre visse angrebsvektorer.

"Hærdede" profiler i nogle distributioner har allerede mange af disse muligheder aktiveret som standard. Manuel aktivering uden at forstå virkningen kan føre til mærkbart langsommere binære filer., især i store eller meget hukommelseskrævende applikationer, men på udsatte servere eller følsomme desktops er det normalt en rimelig pris.

Vælg compiler og miljø: GCC, Clang, MSVC, MinGW, Xcode…

I praksis vælger man ofte ikke bare flag, men Hvilken compiler og hvilken komplet værktøjskæde vil du bruge? på hver platform. GCC og Clang er normalt meget ens i ydeevne, og forskellene er mere mærkbare i diagnosticering, kompileringstider eller kompatibilitet med bestemte udvidelser.

En Windows Du har flere ruter: Visual Studio (MSVC) med deres værktøjssæt v143, v142osv.; eller MinGW-w64 igennem MSYS2 hvilket giver dig native Windows GCC og Clang sammen med de nødvendige Win32-biblioteker. MSYS2 administreres med pacman og tilbyder MinGW64-miljøer (baseret på klassisk MSVCRT) og UCRT64 (med Universal CRT, mere moderne).

På macOS er standardstien Xcode med clang/clang++, hvor nøglekonceptet er Basis-SDK (den systemversion, som den er kompileret til) og Implementeringsmål (den minimale macOS-version, som du vil have din app til at køre på). Ved at justere dette par korrekt undgår du den klassiske katastrofe med kun at kompilere til den nyeste systemversion, hvor dine binære filer ikke kører på lidt ældre versioner.

I Linux er det normale at bruge GCC og Make or NinjaMåske bruge CMake som en metagenerator. Derudover giver distributioner som Ubuntu dig mulighed for at installere flere versioner af GCC og vælge dem med update-alternatives, ligesom hvordan du bruger det i macOS xcode-select at skifte fra Xcode.

Hvis du har brug for komfortable fejlfindingsmiljøer til projekter genereret med Make eller Ninja (som har én konfiguration), Eclipse CDT y Visual Studio Code Dette er to meget praktiske muligheder: CMake kan producere de projektfiler, du har brug for, eller integrere direkte med dem for at konfigurere, kompilere og fejlfinde.

Portabilitet og CMake: samme kode, forskellige værktøjskæder

At få et C/C++-projekt til at kompilere uden at røre koden på Windows, Linux og macOS kræver en god kombination af begge dele. CMake, de tilgængelige generatorer og de forskellige compilereIdeen er, at filen CMakeLists.txt Beskriv projektet på en abstrakt måde, og CMake vil generere den passende projekttype på hver platform.

I Windows kan du kalde CMake med -G "Visual Studio 17 2022" at producere en løsning med msbuild, eller med -G "Ninja" for at få hurtigere builds fra konsollen. Derudover gennem -T v143, v142osv., vælger du Platform Toolset (MSVC compiler-version) og med -A x64, Win32 o arm64 Du vælger arkitekturen.

Med MinGW/MSYS2 er det normalt at bruge -G "MinGW Makefiles" o -G "Ninja" og gennem variablerne CMAKE_C_COMPILER y CMAKE_CXX_COMPILERVælg om du vil have GCC eller Clang. I dette tilfælde styres konfigurationerne (Debug, Release osv.) via -DCMAKE_BUILD_TYPE, da Make og Ninja har én konfiguration.

På macOS, -G Xcode Det giver dig et perfekt projekt til fejlfinding i IDE'en, og du kan styre SDK'et og Deployment Target med variabler som CMAKE_OSX_DEPLOYMENT_TARGETHvis du kun vil have Make eller Ninja, bruger du de samme generatorer som i Linux.

Det smukke ved alt dette er, at du, korrekt konfigureret, kan vedligeholde en enkelt kodebase og et ensartet sæt af flag (nogle gange platformspecifikke) og kompilere i ethvert miljø uden konstant at skulle pille ved kildekoden. Det er dog vigtigt at huske hovedprincippet: Først skal du sørge for, at det fungerer korrekt, derefter fremskynder vi optimeringsprocessen..

Med alt set er den generelle idé at holde sig til en moderat, men effektiv kombination (noget i stil med dette) -O2 -march=<cpu adecuada> -pipe plus en rimelig hærdning) og reserver de store kanoner — LTO, PGO, Graphite, aggressiv OpenMP — til de projekter eller moduler, hvor forbedringerne virkelig måles, og de vedligeholdelses- og fejlfindingsomkostninger, de medfører, accepteres.