{"id":121307,"date":"2025-01-11T09:46:03","date_gmt":"2025-01-11T07:46:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-fedora-42-planiruyut-postavlyat-optimizirovannye-varianty-ispolnyaemyh-fajlov"},"modified":"2025-01-11T09:46:03","modified_gmt":"2025-01-11T07:46:03","slug":"v-fedora-42-planiruyut-postavlyat-optimizirovannye-varianty-ispolnyaemyh-fajlov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/v-fedora-42-planiruyut-postavlyat-optimizirovannye-varianty-ispolnyaemyh-fajlov","title":{"rendered":"Fedora 42 is planning to offer optimized versions of executable files","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In the upcoming Fedora 42 release, scheduled for late April, it is proposed to allow maintainers to include additional executable file variants in packages that are compiled with optimizations for the x86-64-v2, x86-64-v3, and x86-64-v4 microarchitectures. It is noted that Fedora continues to compile packages for the x86-64-v1 architecture, while CentOS uses the x86-64-v2 architecture for compilation, and RHEL 10 uses x86-64-v3. In most cases, the performance gain from building for such architectures does not exceed 10%, but in some situations, it results in a significant performance increase (up to 120%). The proposal has not yet been approved by the FESCo (Fedora Engineering Steering Committee), which is responsible for the technical aspect of Fedora distribution development. <\/p>\n
Fedora already allows the distribution of additional libraries optimized for advanced versions of the x86_64 architecture, and this capability is now planned to be extended to executable files. The loading of optimized library implementations is performed by the dynamic linker, which checks for the presence of additional variants in the glibc-hwcaps subdirectories located in the filesystem areas scanned during library searches (e.g., \/usr\/lib64\/glibc-hwcaps\/x86-64-v2). <\/p>\n
For executable files, it is proposed to use the hwcaps-loader layer, which will select and execute the variant of the executable that matches the capabilities of the current system. For packages that provide multiple variants of executable files, this layer should be exposed through a symbolic link. The decision to add additional optimized executable files will be made by maintainers based on the performance testing results of specific packages. <\/p>\n
The x86-64-v* versions define an unofficial method for identifying microarchitecture state slices that encompass certain sets of extensions: <\/p>\n
\n
x86-64-v2 encompasses the SSE3, SSE4_2, SSSE3, POPCNT, LAHF-SAHF, and CMPXCHG16B extensions.\n
x86-64-v3 \u2014 AVX, AVX2, BMI2, FMA, LZCNT, MOVBE, and SXSAVE.\n
x86-64-v4 \u2014 AVX512F, AVX512BW, AVX512CD, AVX512DQ, and AVX512VL. <\/ul>\n
Additionally, it is worth noting the proposal for unifying the update of grub and shim bootloaders in both atomic and standard versions of Fedora. Instead of updating the contents of the \/boot and \/boot\/efi directories through a script call during the installation of the rpm package, it is suggested to utilize the bootupd tool for bootloader updates, which is already employed in the atomic-update variants of Fedora. In the rpm packages containing bootloaders, the content is advised to be installed not directly into the \/boot and \/boot\/efi directories, but into a separate directory within the \/usr partition, after which the contents of \/boot and \/boot\/efi should be synchronized with it. This approach will allow for a backup boot option that can be used to revert to an old configuration in case of issues following a bootloader update. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"