Optimalizace binárních souborů v C/C++ pomocí GCC a Clang

Když začnete experimentovat s možnostmi kompilace v jazyce C a C++, snadno se necháte lákat k povolení všech těch „cool“ parametrů, které vidíte online. Realita je ale taková, že špatná kombinace parametrů může způsobit nestabilitu systému, přerušit kompilaci nebo, co je horší, generovat binární soubory, které selhávají velmi nenápadně nebo vyžadují extrakci informací; v těchto případech může být užitečné extrahovat skrytý text z binárních souborů pro účely zkoumání.

Cílem této příručky je, abyste praktickým a srozumitelným způsobem pochopili, jak Optimalizace binárních souborů v C/C++ pomocí GCC a Clang s použitím správných možností: od klasických -O2, -march y -pipe...až po pokročilé techniky, jako jsou LTO, PGO, OpenMP, Graphite a posílení zabezpečení. Uvidíte také, jak se to vše propojuje s CMake, MinGW/MSYS2, Visual Studio, Xcode nebo Ninja a umožňuje tak vytvořit přenosné a snadno udržovatelné prostředí.

Co jsou CFLAGS a CXXFLAGS a jak je používat, aniž bychom to zpackali?

Téměř ve všech typech systémů Unix (Linux, BSD atd.) se používají proměnné CFLAGS y CXXFLAGS předat možnosti kompilátoru C a C++. Nejsou součástí žádného formálního standardu, ale jsou tak běžné, že je respektuje jakýkoli dobře napsaný sestavovací systém (Make, Autotools, CMake, Meson…).

V distribucích jako Gentoo jsou tyto proměnné definovány globálně v /etc/portage/make.confOdtud je dědí všechny balíčky kompilované pomocí Portage. Na jiných systémech je můžete exportovat do shellu nebo je umístit do... Makefile, zajišťuje také účinek skript z CMake nebo podobného.

Je docela běžné definovat CXXFLAGS opětovné použití obsahu CFLAGS a v případě potřeby přidejte jakékoli specifické možnosti pro C++. Například: CXXFLAGS="${CFLAGS} -fno-exceptions"Důležité je nepřidávat tam příznaky bez rozdílu, protože ty budou aplikovány na vše, co kompilujete.

Je důležité si uvědomit, že agresivní volby CFLAGS/CXXFLAGS mohou narušit kompilace , způsobit chyby, které je velmi obtížné ladit, nebo dokonce zpomalit binární soubory. Vysoká úroveň optimalizace ne vždy zlepšuje výkon a některé transformace mohou zneužívat předpoklady, které váš kód nesplňuje.

Základní optimalizace: úrovně -march, -mtune a -O

Základ každé rozumné úpravy se skládá ze tří částí: Vyberte architekturu CPU, zvolte úroveň optimalizace a někdy aktivujte malá, neškodná vylepšení. jak -pipeTéměř všechno ostatní by mělo přijít později a s čistou hlavou.

Výběr architektury: -march, -mtune a společnost

Volba -march=<cpu> říká GCC/Clang, která konkrétní rodina procesorů vůle vygenerovat kódUmožňuje použití specifických instrukcí (SSE, AVX, AVX2, AVX-512 atd.) a úpravy ABI. Pokud jste příliš chytří a zvolíte příliš moderní CPU, binární soubor se na starších počítačích jednoduše nespustí.

Chcete-li zjistit, co váš procesor podporuje, v Linuxu se můžete podívat na /proc/cpuinfo nebo použití příkazy ze samotného kompilátoru stylů gcc -Q -O2 --help=targetV moderních systémech x86-64 byly generické profily standardizovány, jako například x86-64-v2, x86-64-v3 y x86-64-v4které seskupují rostoucí sady instrukcí a jsou podporovány od GCC 11.

Kromě -march, existuje -mtune=<cpu> „doladit“ plánování z kódu do konkrétního modelu bez použití nových instrukcí. Objevují se také v architekturách jiných než x86 -mcpu y -mtune Mezi relevantní možnosti patří (ARM, PowerPC, SPARC…). V x86, -mcpu Ve skutečnosti je to zastaralé.

Často používaný trik je -march=nativeTo umožňuje kompilátoru detekovat CPU lokálního počítače a automaticky aktivovat příslušná rozšíření. To je ideální v prostředích, kde budete binární soubory spouštět pouze na stejném počítači, kde je kompilujete, ale je to smrtelná past, pokud generujete balíčky pro jiné CPU.

V nedávných procesorech Intel A AMD, GCC zahrnuje specifické názvy pro každou rodinu, například -march=rocketlake, -march=sapphirerapids, -march=znver2 o -march=znver3Tyto možnosti seskupují pokročilé instrukce (AVX2, AVX-512, FMA atd.) každé generace a umožňují vám z nich vytěžit značné množství. technické vybavení když víte, kam se chystáte nasadit.

Úrovně optimalizace -O: kdy je použít

Volba -O řídí celkovou úroveň optimalizace aplikováno na kód. Každý krok aktivuje širší sadu transformací, což má vliv jak na dobu kompilace a spotřebu paměti, tak na snadnost ladění.

• -O0Neoptimalizované. Toto je výchozí možnost, pokud nic neurčíte. Kompiluje se rychle a generuje kód, který se velmi snadno ladí, ale je pomalý a rozsáhlý. Ideální pro raný vývoj a zkoumání složitých chyb.
• -O1První úroveň optimalizace. Aplikuje relativně levná vylepšení, která obvykle poskytují slušné zvýšení výkonu, aniž by kompilace byla příliš náročná.
• -O2: je doporučená úroveň pro všeobecné použití ve většině projektů. Nachází dobrou rovnováhu mezi výkonem, dobou kompilace a stabilitou., a proto je to hodnota, kterou mnoho distribucí používá standardně.
• -O3: aktivuje všechny optimalizace -O2 Agresivnější transformace, jako je velmi silné odvíjení smyčky nebo intenzivnější vektorizace. To může fungovat skvěle v některých numerických kódech, ale je také pravděpodobnější, že to odhalí UB v kódu nebo nafoukne velikost spustitelného souboru.
• -OsToto se pokouší zmenšit velikost binárního souboru upřednostněním prostoru před rychlostí. Je to užitečné v prostředích s skladování nebo velmi omezenou mezipaměť.
• -Oz (GCC 12+): posouvá úspory velikosti do extrému a akceptuje značné poklesy výkonu. Užitečné pro velmi malé binární soubory nebo velmi specifické scénáře.
• -OfastJe to jako -O3 Nedodržuje striktně standardy C/C++. Umožňuje porušit některé jazykové záruky a dosáhnout tak vyššího výkonu, zejména při výpočtech s plovoucí desetinnou čárkou. Musíte jej používat s plným pochopením toho, co děláte.
• -OgNavrženo pro ladění. Aplikuje pouze optimalizace, které příliš nezasahují do ladicího programu, a ponechává kód v polovině mezi -O0 y -O1.

Úrovně nad -O3 jak -O4 o -O9 Všechno jsou to jen kouř a zrcadlaKompilátor je akceptuje, ale interně s nimi zachází jako -O3Není v tom žádná skrytá magie, jen pózování.

Pokud se vám začne zobrazovat sestavení, která záhadně selhávají, dochází k podivným pádům nebo se výsledky liší v závislosti na optimalizátoru, je vhodné provést diagnostický krok. dočasně klesnout na -O1 nebo dokonce -O0 -g2 -ggdb získat snadno laditelné binární soubory a nahlásit chybu s užitečnými informacemi.

-potrubí a další základní možnosti

vlajka -pipe říká kompilátoru, aby v paměti použil roury Místo dočasných souborů na disku mezi fázemi kompilace (předzpracování, kompilace, assembly). Obvykle to proces poněkud urychlí, i když to spotřebuje více RAM. Na počítačích s velmi malým množstvím paměti to může způsobit pád kompilátoru, proto to v takových případech používejte střídmě.

Další tradiční možnosti, jako např. -fomit-frame-pointer Umožňují uvolnit registr ukazatele zásobníku pro generování dalšího kódu, ale ztěžují ladění s čistými zpětnými trasami. Na moderních architekturách x86-64 si s tím kompilátor docela dobře poradí a často to ani není nutné ručně nastavovat.

SIMD rozšíření, Graphite a vektorizace smyček

Moderní kompilátory pro x86-64 automaticky povolují mnoho SIMD instrukcí v závislosti na zvoleném CPU. -marchI tak uvidíte vlajky jako -msse2, -mavx2 nebo podobné, které lze explicitně přidat.

Obecně platí, že pokud používáte -march To je vhodné; nemusíte to aktivovat ručně. -msse, -msse2, -msse3, -mmmx o -m3dnowprotože jsou již ve výchozím nastavení povoleny. Vynutit je má smysl pouze na velmi specifických procesorech, kde je GCC/Clang ve výchozím nastavení nepovoluje.

Pro složité smyčky GCC zahrnuje sadu optimalizací Grafitkteré se spoléhají na knihovnu ISL. Prostřednictvím příznaků, jako například -ftree-loop-linear, -floop-strip-mine y -floop-block Kompilátor analyzuje smyčky a může je restrukturalizovat, aby zlepšil lokalitu dat a paralelizaci; specifické případy viz příklady nízkoúrovňového C Pomáhá to přizpůsobit kód těmto transformacím.

Tyto transformace mohou přinést dobré výsledky v náročném numerickém kódu, ale nejsou neškodné : mohou výrazně zvýšit spotřebu paměti RAM během kompilace a způsobit chyby ve velkých projektech, které s nimi nebyly napsány. Proto se doporučuje povolit je pouze v určitých částech kódu nebo projektech, kde byly testovány a prokázalo se, že fungují správně.

Paralelismus: OpenMP, smyčky -fopenmp a -ftree-parallelize

Pokud váš kód používá OpenmpGCC i Clang nabízejí poměrně solidní podporu prostřednictvím této možnosti -fopenmpTo umožňuje paralelizaci částí kódu, zejména smyček, pomocí direktiv ve zdrojovém kódu samotném a kompilátoru generovat práci ve více vláknech.

Kromě -fopenmpGCC obsahuje možnost -ftree-parallelize-loops=NKde N Obvykle se nastavuje na počet dostupných jader (například pomocí $(nproc) (ve skriptech pro sestavení). Toto se pokouší automaticky paralelizovat smyčky bez nutnosti ručního přidávání direktiv, ačkoli úspěch silně závisí na tom, jak je kód napsán.

Mějte na paměti, že Globální povolení OpenMP v celém systému může být velmi problematické.Některé projekty na to nejsou připraveny, jiné používají vlastní modely souběžnosti a některé se po setknutí s kompilací prostě nezkompilují. -fopenmpRozumné je povolit to pro každý projekt nebo dokonce pro každý modul, ne v globálních CFLAGS systému.

Optimalizace doby propojení: LTO

Optimalizace doby linkování (LTO) umožňuje kompilátoru, aby se při optimalizaci neomezoval na jeden zdrojový soubor, ale aby viděl celý program během fáze linkování a aplikoval globální optimalizace na všechny zúčastněné objekty.

V GCC se aktivuje pomocí -fltoa lze zadat například počet vláken -flto=4nebo ho nechat detekovat počet jader s -flto=autoPokud se také používá -fuse-linker-plugin spolu s linkerem zlato A s pluginem LTO nainstalovaným v binutils může kompilátor extrahovat informace LTO i ze statických knihoven zapojených do vazby.

LTO obvykle produkuje menší a v mnoha případech rychlejší spustitelné soubory, protože eliminuje nefunkční kód a umožňuje vkládání mezi moduly. Doba kompilace a spotřeba paměti se však výrazně zvyšují, zejména u velkých projektů s tisíci objektovými soubory.

V prostředích, jako je Gentoo, kde je celý systém rekompilován ze zdrojového kódu, je globální použití LTO stále považováno za riskantní: mnoho balíčků s LTO zatím nefunguje dobře a vyžaduje jeho selektivní zakázání. Proto se obecně doporučuje povolit jej pouze v konkrétních projektech nebo sestaveních GCC/Clang, kde je jeho přínos skutečně znatelný.

PGO: Optimalizace s průvodcem profilem

Optimalizace řízená profily (PGO) zahrnuje jednorázovou kompilaci programu s instrumentací, jeho spuštění s reprezentativními úlohami za účelem shromáždění statistik výkonu a následnou rekompilaci s využitím těchto profilů pro vedení optimalizátoru.

V GCC je typický tok: nejprve zkompilujte s -fprofile-generatespusťte program (nebo jeho testy) pro generování profilových dat a poté kompilovat s -fprofile-use ukazující na adresář, kde jsou uloženy soubory profilu. S dalšími možnostmi, jako například -fprofile-correction nebo vypnutím určitých oznámení (-Wno-error=coverage-mismatch) lze se vyhnout častým chybám vyplývajícím ze změn kódu mezi fázemi; je to také obvykle užitečné Monitorování výkonu pomocí eBPF a perf k získání přesných profilů.

Při správné implementaci může PGO poskytnout mnohem větší zlepšení výkonu než pouhé zvýšení úrovně -OProtože rozhodování provádí na základě reálných dat z provádění, nikoli na základě generických modelů. Problém je v tom, že se jedná o těžkopádný proces: musí se opakovat s každou relevantní aktualizací kódu a silně se spoléhá na to, aby testovací scénář reprezentoval skutečné použití.

Některé projekty (včetně samotného GCC v určitých distribucích) již nabízejí specifické příznaky nebo skripty pro automatickou aktivaci PGO, ale obecně se jedná o techniku ​​pro pokročilé uživatele, kteří jsou ochotni do procesu investovat čas.

Zpevnění: zabezpečení založené na příznakech

Kromě rychlosti se mnoho prostředí zaměřuje na posílení binárních souborů proti zranitelnostem, a to i za cenu určité ztráty výkonu. GCC a současné linkery nabízejí širokou škálu možností posílení , které lze aktivovat pomocí CFLAGS/CXXFLAGS a LDFLAGS.

Mezi nejběžnější patří:

• -D_FORTIFY_SOURCE=2 o =3: přidává další kontroly určitých funkcí libc pro detekci přetečení vyrovnávací paměti za běhu.
• -D_GLIBCXX_ASSERTIONS: aktivuje kontroly hranic kontejnerů a řetězců C++ v STL a detekuje přístupy mimo rozsah.
• -fstack-protector-strong: vkládá do zásobníku canary pro detekci zápisů, které jej poškozují.
• -fstack-clash-protection: zmírňuje útoky založené na kolizích mezi zásobníkem a jinými oblastmi paměti.
• -fcf-protection: přidává ochranu toku řízení (např. proti útokům ROP) na architekturách, které ji podporují.
• -fpie spolu s -Wl,-pie: generuje polohovatelné spustitelné soubory, nezbytné pro efektivní ASLR.
• -Wl,-z,relro y -Wl,-z,nowZvyšují odolnost relokační tabulky a zakazují líné vázání symbolybránění určitým vektorům útoku.

„Zpevněné“ profily v některých distribucích již mají mnoho z těchto možností ve výchozím nastavení povoleno. Jejich ruční povolení bez pochopení dopadu může vést k znatelně pomalejším binárním souborům , zejména u velkých nebo paměťově náročných aplikací, ale na exponovaných serverech nebo citlivých počítačích je to obvykle rozumný kompromis.

Vyberte kompilátor a prostředí: GCC, Clang, MSVC, MinGW, Xcode…

V praxi si často vybíráte nejen příznaky, ale také kompilátor a kompletní sadu nástrojů, které chcete na každé platformě použít . GCC a Clang jsou si obvykle velmi podobné ve výkonu a rozdíly jsou znatelnější v diagnostice, době kompilace nebo kompatibilitě s určitými rozšířeními.

En Windows Máte několik tras: Visual Studio (MSVC) s jejich sadami nástrojů v143, v142atd.; nebo MinGW-w64 přes MSYS2 který vám poskytuje nativní Windows GCC a Clang spolu s potřebnými knihovnami Win32. MSYS2 je spravován pomocí pacman a nabízí prostředí MinGW64 (založené na klasickém MSVCRT) a UCRT64 (s Universal CRT, modernější).

V systému macOS je standardním přístupem Xcode s clang/clang++, kde klíčovými koncepty jsou Base SDK (verze systému, pro kterou kompilujete) a Deployment Target (minimální verze macOS, na které chcete aplikaci spustit). Správné zarovnání těchto dvou konceptů zabrání klasické katastrofě, kdy se kompiluje pouze pro nejnovější verzi systému a binární soubory se nespustí na o něco starších verzích.

V Linuxu je normální používat GCC a Make nebo NinjaMožná použití CMake jako metagenerátoru. Distribuce jako Ubuntu navíc umožňují instalaci více verzí GCC a jejich výběr pomocí update-alternatives, podobně jako v macOS xcode-select přepnout z Xcode.

Pokud potřebujete pohodlné ladicí prostředí pro projekty generované pomocí Make nebo Ninja (které mají jednu konfiguraci), Eclipse CDT a Visual Studio Code jsou dvě velmi užitečné možnosti: CMake dokáže vytvořit potřebné soubory projektu nebo se s nimi přímo integrovat pro konfiguraci, kompilaci a ladění.

Přenositelnost a CMake: stejný kód, různé sady nástrojů

Kompilace projektu v C/C++ bez nutnosti zásahu do kódu ve Windows, Linuxu a macOS vyžaduje dobrou kombinaci obou. CMake, dostupné generátory a různé kompilátoryMyšlenka je, že soubor CMakeLists.txt Popište projekt abstraktním způsobem a CMake vygeneruje vhodný typ projektu na každé platformě.

Ve Windows můžete CMake spustit pomocí -G "Visual Studio 17 2022" vytvořit řešení pomocí msbuildu nebo pomocí -G "Ninja" pro rychlejší sestavení z konzole. Navíc prostřednictvím -T v143, v142atd., vyberete sadu nástrojů platformy (verze kompilátoru MSVC) a pomocí -A x64, Win32 o arm64 Architekturu si vyberete vy.

S MinGW/MSYS2 se obvykle používá -G "MinGW Makefiles" o -G "Ninja" a prostřednictvím proměnných CMAKE_C_COMPILER y CMAKE_CXX_COMPILERVyberte, zda chcete GCC nebo Clang. V tomto případě jsou konfigurace (Debug, Release atd.) ovládány pomocí -DCMAKE_BUILD_TYPE, protože Make a Ninja mají jednu konfiguraci.

V systému macOS -G Xcode Poskytuje vám perfektní projekt pro ladění v IDE a můžete ovládat SDK a cíl nasazení pomocí proměnných, jako je CMAKE_OSX_DEPLOYMENT_TARGETPokud chcete pouze Make nebo Ninja, použijete stejné generátory jako v Linuxu.

Krása toho všeho spočívá v tom, že při správném nastavení můžete udržovat jednu kódovou základnu a konzistentní sadu příznaků (někdy specifických pro danou platformu) a kompilovat v jakémkoli prostředí, aniž byste museli neustále upravovat zdrojový kód. Je však důležité pamatovat na zlaté pravidlo: nejdříve se ujistěte, že to funguje dobře; pak můžeme zvýšit optimalizaci.

Po všem viděném je obecnou myšlenkou držet se mírná, ale účinná kombinace (něco takového) -O2 -march=<cpu adecuada> -pipe plus určité rozumné posílení) a ty velké zbraně – LTO, PGO, Graphite, agresivní OpenMP – si nechat pro ty projekty nebo moduly, u kterých jsou vylepšení skutečně měřitelná a náklady na údržbu a ladění, které s sebou nesou, akceptovány.