Can we have v3 image for fedora as ubuntu

can we have a v3 image for x86-64 as it can be as ubuntu have that and it makes sense. Look at the benchmark.

1 Like

For background this is the discussion around going to x86_64-v2 that did not happen: Search results for "X86_64-v2 in fedora" - devel - Fedora Mailing-Lists

Going to x86_64-v3 will encounter the same issues I expect.

Note that use of hardware features can be done be using the glibc hwcap feature.

It seems that the improvements are marginal gains, except in the synthetic benchmark.

Is it worth stopping Fedora working on some hardware for the marginal gain?

2 Likes

For v2 I wholeheartedly believe it’s worth it, considering how old it is and that there isn’t many hardware left in the wild that is still being used and that wouldn’t be able to run on it, v3 is more debatable though.

1 Like

I believe Fedora should move to v2 as default and have v3 RPMs available for install, recently RPM added support for the x86_64 microarchitectures, so it should be possible to build the same package with x86_64-v2 and x86_64-v3 variants and have dnf pick what is best (dunno about the ostree variants though).

If that is done it would be a matter of just having an extra image that has the v3 variants pre-installed whenever possible but otherwise fallback to the v2 ones.

1 Like

Apparently this is not true as Intel (got io love em) ship new CPUs that do not meet the v2 level.

Also if you read the thread from fedora devel I linked to you will see that v2 is not worth it.

Most of the apps and libraries that could use the newer instructions already switch to code that is CPU dependent to get the performance gains.

This just dropped: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

Not sure how difficult it’d be for the Atomic teams to implement (or even if it’d be possible), but it’d be great if it was as simple as rebasing to a version using the different architectures.

Yes just make another iso for old systems.

In the past there has not been enough infrastructure or people to do the extra development, builds and testing.

I think v3 only make really sense and also it gives improvement. I really don’t think people will use old ancient systems with v2 and they use fedora on that system the percentage will be negligible.

Looks like you can see the flags of what your computer supports with an lscpu command. My AMD Ryzen 7 2700U supports SSE[2,3,4_1,4_2] (v2) and AVX [2] (v3), but sadly no AVX-512 (v4). Would love to see what that’s about, but excited for the glibc-hwcaps mechanism and potentially getting the v3 optimization in a future release.

While it’s possible to manually figure out the x86_64 feature level via manually checking the lscpu output, I believe it’s eneven easier with ld.so:

$ ld.so --help
<snip>
This program interpreter self-identifies as: /lib64/ld-linux-x86-64.so.2

Shared library search path:
  (libraries located via /etc/ld.so.cache)
  /lib64 (system search path)
  /usr/lib64 (system search path)

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)
1 Like

Meanwhile I found out my 2020 Laptop is v4 haha, thats not brand new either.

And my damn 2012 3rd Gen Intel Thinkpad had v3, which I only keep because its kinda cool.

Especially with immutable distros, this may be a bit harder because there are (at least currently) no different images for every version and ublue has not even aarch64 support.

But not supporting any of those features from 12 years ago sounds crazy? Is Fedora a distro for 13+ years old PCs?

A full rebuild for v3 is a massive waste of resources. A replacement build for v3 is unacceptable as it excludes a whole lot of hardware where Fedora us currently used. In reality, there are a small number of packages where you will see performance improvements. The hwcaps change moves us a good bit in that direction.
In the future, it might also be worth adding a hwcaps type feature to dnf/rpm so you could have multiple versions of the specific packages that matter which are “preferred” by dnf. Meaning if I have a system with avx-512, there could be a libfoo-1.0-1.x86_64 and a libfoo-1.0-1.x86_64.avx512 and dnf would choose the avx-512 version. But if I don’t it would just install the base arch version. This could be extended to several specific features and not just cpu, and would be fairly lightweight.

4 Likes

I think to make a clear decision, telemitry data using a tool like this one is needed, to see how many users would actually benefit/suffer from such a change.