Last week, the ISA SIG concluded two rebuilds of a snapshot of CentOS 9 Stream with GCC 12, one with -march=x86-64-v2 (same as CentOS 9 Stream), and one with -march=x86-64-v3.
The rebuilds are fairly complete. The following things are missing:
* All modular content. * LibreOffice and OpenJDK. * Two Rust packages which require a rebase of their bundled rust-bindgen versions for Clang 16 compatibility. (Rust currently does not follow the subarchitecture in CFLAGS anyway.)
I classifed most of the initial build failures, and here are some numbers:
GCC 12 induced failures GCC 12 exposes latent undefined behavior 2 various issues (mostly -Werror) 18 GCC 12 C++ header inclusion changes 3 subtotal 23 x86-64-v3 test differences 7 general buildroot/time/policy changes 19 grand total 49
(We switch to GCC 12 for auto-vectorization at -O2 using the very-cheap cost model, something that cannot be model with GCC 11 compiler flags. Without that, a forward-looking comparison between -march=x86-64-v2 and -march=x86-64-v3 is not possible.)
The x86-64-v3 test differences are mostly due to GCC's -ffp-contract=fast default, which does not match what some package test suites expect. We saw those on other architectures already, and with -march=x86-64-v3, GCC supports FMA, exposing them for the x86_64 architecture as well. Maybe upstream GCC can revisit the default there.
The general failures are in some cases literally due to time because test certificates expired, or a hard-coded date in some test is no longer in the future. Disabling SHA-1 broke some tests as well. The rest is just general drift of build dependencies, introducing incompatibilities. FTBFS bugs have been filed in Red Hat Bugzilla as appropriate.
We were able to eliminate a bunch of rebuild issues that are specific to the CBS Koji environment and do not show up in other environments. I should probably send out a separate note about that, in case other SIGs want to do mass rebuilds.
We are still working out how to best deliver the rebuilt packages for testing. Until then, the packages are available from the Koji buildroot and can be (mostly) installed with “dnf distro-sync” from an existing CentOS 9 Stream system:
https://cbs.centos.org/kojifiles/repos/isa9s-packages-baseline-el9sbase-build/latest/x86_64/ https://cbs.centos.org/kojifiles/repos/isa9s-packages-optimized-el9sopt-build/latest/x86_64
I would like to thank Troy Dawson for shepherding the build process and reviewing and fixing issues, and Brian Stinson for resolving CBS Koji infrastructure issues.
Florian
Since we're build x86-64-v3, can we consider to add AVX2 deflate optimization for Zlib? Thanks to all for your hard work and efforts
On 28/06/2023 16:09, Florian Weimer wrote:
I would like to thank Troy Dawson for shepherding the build process and reviewing and fixing issues, and Brian Stinson for resolving CBS Koji infrastructure issues.
On Wed, 28 Jun 2023 16:39:14 +0300 Ali Erdinc Koroglu aekoroglu@linux.intel.com wrote:
Since we're build x86-64-v3, can we consider to add AVX2 deflate optimization for Zlib? Thanks to all for your hard work and efforts
wouldn't it be better to focus on the zlib-ng project to be able to provide hw optimized/accelerated zlib functions?
Dan
On 28/06/2023 16:09, Florian Weimer wrote:
I would like to thank Troy Dawson for shepherding the build process and reviewing and fixing issues, and Brian Stinson for resolving CBS Koji infrastructure issues.
-- Ali Erdinc Koroglu Intel, SSE | Linux OS Systems Engineering _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 28/06/2023 17:17, Dan Horák wrote:
On Wed, 28 Jun 2023 16:39:14 +0300 Ali Erdinc Koroglu aekoroglu@linux.intel.com wrote:
Since we're build x86-64-v3, can we consider to add AVX2 deflate optimization for Zlib? Thanks to all for your hard work and efforts
wouldn't it be better to focus on the zlib-ng project to be able to provide hw optimized/accelerated zlib functions?
I'm gonna submit a change proposal to replace zlib to zlib-ng for F41 or F42 but I don't think that even CentOS Stream 11 or RHEL11 can use that. So what I'm offering is since we did not brake any API/ABI in Zlib, AVX2 deflate optimization applicable for CentOS ISA SIG x86-64-v3
On Wed, Jun 28, 2023 at 11:09 AM Ali Erdinc Koroglu aekoroglu@linux.intel.com wrote:
On 28/06/2023 17:17, Dan Horák wrote:
On Wed, 28 Jun 2023 16:39:14 +0300 Ali Erdinc Koroglu aekoroglu@linux.intel.com wrote:
Since we're build x86-64-v3, can we consider to add AVX2 deflate optimization for Zlib? Thanks to all for your hard work and efforts
wouldn't it be better to focus on the zlib-ng project to be able to provide hw optimized/accelerated zlib functions?
I'm gonna submit a change proposal to replace zlib to zlib-ng for F41 or F42 but I don't think that even CentOS Stream 11 or RHEL11 can use that. So what I'm offering is since we did not brake any API/ABI in Zlib, AVX2 deflate optimization applicable for CentOS ISA SIG x86-64-v3
Why not submit it for Fedora 39 or Fedora 40? Then we can bring it into CentOS Stream 10. Folks in the Hyperscale SIG would be interested in helping with that.
Another alternative would be to switch to zstd as the zlib implementation (which is also possible).
-- 真実はいつも一つ!/ Always, there's only one truth!
* Ali Erdinc Koroglu:
I'm gonna submit a change proposal to replace zlib to zlib-ng for F41 or F42 but I don't think that even CentOS Stream 11 or RHEL11 can use that. So what I'm offering is since we did not brake any API/ABI in Zlib, AVX2 deflate optimization applicable for CentOS ISA SIG x86-64-v3
I think zlib-ng has a build mode that is supposed to be ABI-compatible. We have plans to evaluate that at Red Hat. If it's indeed compatible, we can just swap it out in a Fedora release and consider what to do next.
We currently carry some zlib patches with architecture-specific optimizations, but the original upstream is not willing to take those patches, and the various downstream patches cause maintenance issues. The presence of IFUNC resolvers introduces crashes into some third-party applications because these symbols are frequently interposed, causing relocation ordering problems.
Thanks, Florian