Vlákno názorů k článku
Arch Linux koketuje s myšlenkou x86-64-v3 portu od mhi - Rikam si kam tento svet speje ... na...

Rikam si kam tento svet speje ... na reseni tohoto problemu a multi-arch knihoven by byla krasnym resenim FAT BINARY, jen by se verze x86_64 pridaly jako dalsi "architektura" (resp. nejaka subarchitektura, zjednodusuji, tech polozek na matchnuti by to chtelo asi vice). No a dynloader by si vybral nejlepsi moznost, takze by nic nebranilo aplikaci pro zakladni x86_64 aby se propojila s glibc ktere ma strcmp pres nejake AVX apod.

Fat Binary sa používajú keď chceš vytvoriť jednu binárku pre niekoľko rozdielných architektur, narp x86_64 a PowerPC, alebo x86_64 a ARM64. Pozri wiki: https://en.wikipedia.org/wiki/Fat_binary

Dynamic Scheduling ti zabezpečí, že bude jedna binarka jednej architektúry, ktorá bude mať v sebe "navyše" niekoľko ďalších "code paths" pre procesory, ktoré podporujú dané inštrukcie.

V Linuxe na systémovej úrovni to rieši glibc a HWCAPS, kde je niekoľko rozličných bináriek pre tú istú knižnicu, každá so svojou vlastnou optimalizáciou a dynamický linker sa rozhodne (aj na základe cpuid), ktorú z nich použije.

Samotné binárky to potom už nemusia riešiť samostatne vo svojej réžii.

Presne tak ako vravíš. HWCAPS je novinka v GLIBC 2.33, ktorá vyšla 1. februára 2021, čiže predpokladám, že dosť málo ľudí o tejto feature vôbec vie.
vid link na phoronix: https://www.phoronix.com/scan.php?page=news_item&px=Glibc-2.33-Coming-HWCAPS

Uplne stejne ale muzes fat binary pouzit pro x86_64 a x86_64_v3 - nevidim duvod, proc by to nemelo jit.

Fat binary umi libovolne kombinace, ale to neni podstatne, jak pise nekdo nize mechanismus jde pouzit i na ty verze x86_64. Nevyhoda je ze by se duplikovalo dost kodu

Uplne nejspravnejsi by myslim byla fat binary a neco na zpusob tech HWCAPS (jak pise zase nekdo dalsi vyse) kombinovany s individualni exportni tabulkou symbolu. To by zajistilo myslim nejmensi overhead.