F45 Change Proposal: Build x86-64-v3 Packages [SystemWide]

Project Discussion Change Proposals
, ,
21

So, just so I understand, all the current fedora x86_64 builders are -v3 capable (and future RFPs will add that as an additional requirement) so that tests that are run on the builders will properly execute. While it seems likely (-v3 is rather old at this time), I know of some places that have the most interesting collection of older hardware.

I have this vague recollection that a 3rd party repo has had some issues because all their builders were not -v3 capable (and when building for EL10, some builds would fail).

22

Yes. All the Fedora builders are v3 capable because it was required for ELN to work. So from a Fedora Koji and COPR perspective, things are fine.

Well, no? Only DNF5 needs changing. Fedora no longer ships DNF4 out of the gate anymore.

1 Like
23

How about bumping the base to v3 and crating -v1 for backward compatibility?

24

How does this help? We would be building for both v1 and v3 to do it.

1 Like
25

That’s a better idea.

26

I think shipping only v2 would be better for now. The processors that are on v1 are getting their support dropped gradually. Plus these processors are an even smaller minority.

27

Okay, I’m going to repeat some things here and try to give some history. I’m also not perfect, so I may remember things slightly incorrectly or not understand new things perfectly. Saying that, people seem pretty confused in the thread and the Change Proposal could probably have used a bit more detail to help everyone.

First off, to see what your machines support you can run: /lib64/ld-linux-x86-64.so.2 --help | grep -E "v[0-9]"

Some history of micro/sub arches in Fedora:

For the initial Fedora Core 1 we had i686 as well as i386 for a couple of packages, Basically the three: glibc; kernel; openssl. The idea was that getting a performance boost on those packages was worth a lot, and if you had an older CPU than you’d still get the i386 version and everything would work. Everybody installed everything via. packages (through anaconda/kickstart the first time which was fine being i386 only and then yum), so this was “mostly” easy to solve as the package installer looked at which package to install it would pick the i686 or i386 arch depending on your capabilities.

This continued upto Fedora 10 but by Fedora 12 almost all of the packages were i686, but obviously we had 5 years of speedups for the couple of packages.

It wasn’t perfect though, even then, as some people would randomly provide i686/i586 packages outside of the distro. and the package manager had to deal with a bunch of edge cases for things like “there’s a newer package available but it’s only i586 and i386, but we have the i686 one installed right now” 
 where different people could realistically expect/want different results. It’s fair to say that when we moved to x86_64 and had a single arch again, a lot of people sighed with relief (as they tried to not think about multilib ;).

However we don’t live in the same world as Fedora Core 1. Package installers are not the only way people use Fedora. We have live installers, containers, VMs, Silverblue/ostree/etc. 
 so to support this feature well a lot more things will need changing/testing than the three outlined in the change proposal.
There’s the problem that users write/use software that isn’t part of the distribution and we haven’t had microarches for ~15 years, so there could be a bunch of random software that thinks the entire world is noarch/x86_64 and maybe aarch64.

Then, as Neal has said, x86_64 can already actually mean v1 or v3 within the Fedora ecosystem. Then there’s the fact that x86_64_v3 is ~13 years old right now and from what I understand v4 is basically unusable as a real std. 
 so this will be a huge cost to developers and users, but will be a small-ish speedup for another couple of releases before everything will be x86_64_v3 arch anyway.

As an alternate proposal we could look at supporting FatELF binaries, and use that for a small number of packages that would benefit the most. This does require a non-trivial amount of work, but that work will be very limited in the scope of which things need to change (and the users of Fedora don’t have any weird issues).

tl;dr

  • This has been tried before, and it wasn’t as fun as the CP is making it out to be.
  • It’s going to be a lot less fun now.
  • We can just move to using v3 flags for x86_64 arch fairly soon anyway.
  • There’s no v4 or v5 etc. to make all the work useful in the future.
  • There is other software we don’t distribute that will have to change due to us adding a new x86_64 arch.
  • The 2x storage alone is a lot for the entire distribution now (what I think the CP wants to do), and it seems unlikely the cost would be worth it for only doing a few packages.
  • x86_64_v3 has to be the most ugly arch name I’ve seen (and others agree as people keep using x86_64-v3 in this thread, but that can’t be used in rpm).
8 Likes
28

I assume newer UBI images could provide fixed labels. How exactly should they be labeled, and what labels should we apply to the new Fedora images?

Note that—regardless of the labels—Podman (at least regarding the Mock issue) seems to prefer pulling the v3 image variant on a v2 system, even when a v3 variant is available in the registry. Providing correct labeling is one part of the solution; ensuring that v2-only distributions can correctly influence Podman’s selection logic is the other.

29

x86_64-v3 images should only be uploaded for platform amd64/v3 instead of as amd64.

Fedora x86_64-v1 images stay amd64 and the new x86_64-v3 images would be amd64/v3.

Right now, we don’t have any v3 distribution correctly marking their images so that the correct one would be selected, even if the logic was implemented.

30

I meant Copr DNF plugin.

31

Creating a separate architecture is a waste of resources and maintainers’ time. I think it would be better to switch x86_64 directly to x86_64-v3. Users with ancient hardware without AVX2 support (~5-7%) can switch to another distributions with legacy hardware support.

AVX2 instructions provide significant performance boost in many cases across supported hardware, such as browsers, archivers, encoding and decoding software.

32

Intel still doesn’t support x86_64-v4 (only AMD does) due to lack of support for AVX-512 instructions (removed by microcode update in 12th Gen).

1 Like
33

I use fedora because I want to. being forced to switch to some other distro for single systems is an absolute no-go for me. I would switch all my systems, no fun though!

1 Like
34

Even Windows 11 started requiring modern instruction sets in 2025.

Yes, it’s a problem, but significantly slowing down 93-95% of machines for just 5-7% of users with older hardware is also undesirable.

3 Likes
35

Creating a separate architecture is a waste of resources and maintainers’ time.

I don’t see how its more of a waste of time than supporting aarch64 or riscv.

2 Likes
36

That’s the problem

This claim is being repeated over and over, but I don’t recall anyone presenting a real world measurement. And I’m not looking for a benchmark of libfftw or lapack that obviously performs better with vector instructions, but rather Firefox, Thunderbird or the desktop.

It would be rather pointless to rebuild the whole distro for a potentially minuscule benefit or outright ban a non-negligible user base that might have been attracted to come to linux, because we still support their hardware.

7 Likes
37

That’s just addressing a problem with a sledgehammer, when in fact we only have to rebuild a limited set of performance critical packages

2 Likes
38

Its silly to limit it to only such a poorly defined subset of applications.
What even defines a performance critical package?

1 Like
39

To reverse the argument, can you show that there is a general benefit to using v3?

I recall a discussion on fedora devel list where there where reports of performance regressions in some apps with v3 (which could be compiler bugs).
There where also reports of massive performance gains.
I think a chess program halved its CPU costs.

That discussion was for a chamnge proposal to only use v3 etc on selected apps.

1 Like
40

This was Stockfish, and you remember correctly. It’s intensively optimized for various SIMD extensions, but you have to choose at compile time. Considering this and the nature of its workload, there are probably few packages that would benefit more from increasing the x86_64 microarchitecture level. Stockfish is not typical by any means. It does show how much some packages may benefit.

1 Like