Fedora Stakeholders Back To Discussing Raising x86_64 Requirements Or Using Glibc HWCAPS

[phoronix]

Phoronix: Fedora Stakeholders Back To Discussing Raising x86_64 Requirements Or Using Glibc HWCAPS

While Red Hat Enterprise Linux 9 is dropping support for older x86_64 CPUs by raising the baseline requirement to "x86_64-v2" that roughly correlates to Intel Nehalem era processors and newer, so far Fedora has not changed its default. There was a proposal shot down last year for raising the x86_64 microarchitecture feature level while now that discussion has been restarted or alternatively making use of Glibc's HWCAPS facility for allowing run-time detection and loading of optimized libraries...

https://www.phoronix.com/scan.php?page=news_item&px=Fedora-2021-x86_64-Level

[chuckula]

I get the urge to retain compatibility with older hardware, but adding HWCAPS is vital to getting performance out of new hardware.

[mifritscher]

This would kill C2D - and I think the only addition is SSE4 (Newer C2D got SSE 4.1, Nehalem 4.2). Is that really worth?
Yes, HWCAPS is the way to go. Partly because Intel often omits things AVX/AVX2/AES-NI etc. even in rather new CPUs soly for marketing reasons - which fragments the market heavily.

Additionally, I don't think that such many libraries benefits at all - I assume that in many cases, the binaries will the even the same. So I don't think that such many "optimized libraries" will be created. And in the majority of them, I assume that only on very few hotspots the extensions will be used - so a runtime decision would be enough without making the libraries significantly bigger.

[Eumaios]

Hello, Linux newbie and absolutely not a developer, but really fascinated by the Linux phenomenon.

I've looked up what HWCAPS are and believe I understand it at a basic level. And it does seem to offer a more flexible solution than raising the base level. But I don't understand when Michael writes that the HWCAPS solution "leaves Linux distributions then to building multiple packages or inflating their packages by carrying multiple builds within there in order to have the libraries comply with the different x86_64 microarchitecture feature levels."

The distributions now don't even have those libraries? How large are the libraries, that it would make the distributions larger? Or, could installing the libraries be done after installing the base system, so that the cost, so to speak, is on the user rather than the provider?

I apologize in advance if these are stupid questions.

[uxmkt]

In fact, even today, you will see e.g. `__strlen_avx2` when stepping through binaries with gdb or so. Therefore, I am currently remaining skeptical whether hwcaps will give any significant boost over the current ifunc-like approach. Of course, if you have numbers to show the contrary, I'm all ears...

[oiaohm]

In fact, even today, you will see e.g. `__strlen_avx2` when stepping through binaries with gdb or so. Therefore, I am currently remaining skeptical whether hwcaps will give any significant boost over the current ifunc-like approach. Of course, if you have numbers to show the contrary, I'm all ears...

The ifunc gets you so far. There are two particular reasons to use dynamic loader hwcaps options.
1) is memory usage ifunc method you still have all the different versions loaded in memory the hwcaps by dynamic loader can be restricted to in memory being the only one you need. This is of course a trade off lower memory usage for higher disc usage due to duplicating all the non changed code in the multi versions of libraries.
2) is supporting optimisations compilers can do for particular cpus with memory alignments and other things. Of course this can backfire.
https://antlarr.io/2021/03/hackweek-...s-in-opensuse/ as seen here. Some cases the more optimised to cpu results slightly slower but more predictable performance. There are other cases that we have had when due to the differences between amd and intel different memory alignments over large sections of the library memory is required to get ideal performance.

I don't see ifunc usage going away. But hwcaps in the dynamic loader does have it uses as well.

https://sourceware.org/git/?p=glibc.git;a=commit;h=1432d38ea04ab5e96f21a38

This different versions of libraries matched to hardware information has been experimented with quite a bit. The performance gains and loses are mostly in the single percentage range as in between 0% to 10% +-. Bigger reason todo this is the case where there is a true incompatibility.

Having the framework for dynamic loading by HWCAPS allows addressing a cpu issue with a library by providing a replacement for that CPU class. This can be important in the case its a CPU quirk that you are working around and what is it cause.

https://www.agner.org/optimize/blog/read.php?i=49#49

This is a historic example from 2009 but stuff like this can still happen. ifunc is not that helpful when you problem is the compiler optimisation logic. You do get cases where X compiler optimisations options are good for A cpu but bad for B and Y compiler optimisations are bad for A cpu but good for B. These screw ball cases ifunc does not help with but hwcaps does. I see that ifunc and hwcaps if you were looking at their functionality as set as two almost overlapping sets in functionality they provide. ifunc will be the small disc usage option if you can use it but then hwcaps is the more flexable option that will handle your nastier issues like cpu preferences for different memory alignment optimisations by cpu to make cpu cache work better.

Of course hwcaps does have the place to allow old systems to still work by installing more libraries and newer systems not to install those libraries so result in a disc saving for the more modern system users over ifunc.

hwcaps and ifunc both are providing slightly different ways of achieving the same kind of functionality with different benefits and downsides. Both really do have their places.

[zxy_thf]

This is a rare case when I'm feeling Debian's naming scheme is more beneficial than verbose.
They can simply reuse multi-arch and put libraries under /usr/lib/x86_64_v2-linux-gnu

[Sonadow]

This is a rare case when I'm feeling Debian's naming scheme is more beneficial than verbose.
They can simply reuse multi-arch and put libraries under /usr/lib/x86_64_v2-linux-gnu

Debian's multiarch implementation was what made me switch from more than seven years of using RPM-based distributions.

Simple yet extensible and extendable.

[oiaohm]

This is a rare case when I'm feeling Debian's naming scheme is more beneficial than verbose.
They can simply reuse multi-arch and put libraries under /usr/lib/x86_64_v2-linux-gnu

Debian's multiarch implementation was what made me switch from more than seven years of using RPM-based distributions.

Simple yet extensible and extendable.

Problem here not that simple. Not all libraries will be different between all the different x86_64 versions. This is why the glibc HWCAPS adds a directory to the lib directory for different versions for different cpus.

The proposed level solution by redhat would not deal with the issue of AMD and Intel being different in the same generation. Those levels are basically attempt to break feature sets by generation.

x86 is a quite a fragmented mess.

[andre30correia]

they should kill old cpu