I would therefore like to discuss the future of the libc6.1-alphaev67
package on alpha. According to popcon, to take with a grain of salt
given the low number of submissions, this package is installed on 20% of
the installations. I wonder if this package is really useful in terms of performance, or if the architecture baseline can be raised to ev67, or
to a ev6 as a compromise. The goal is to stop building this package.
With the removal of the libc6-xen package in glibc 2.32, the only
package still using the hwcap infrastructure is libc6.1-alphaev67. The
hwcap infrastructure consists in upstream support for looking for
libraries in the hwcap directories, plus Debian specific patches to
support disabling hwcap with the /etc/ld.so.nohwcap, plus some mechanism
in the maintainer scripts to disable hwcap support until all libc6
packages are configured.
The various optimized packages have been replaced with time by other mechanisms such as indirect function support (IFUNC), or runtime atomic selection in GCC (-moutline-atomics).
[1] https://www.phoronix.com/scan.php?page=news_item&px=Fedora-2021-x86_64-Level
On Tue, Aug 24, 2021 at 10:59:32PM +0200, Aurelien Jarno wrote:
I would therefore like to discuss the future of the libc6.1-alphaev67 package on alpha. According to popcon, to take with a grain of salt
given the low number of submissions, this package is installed on 20% of the installations. I wonder if this package is really useful in terms of performance, or if the architecture baseline can be raised to ev67, or
to a ev6 as a compromise. The goal is to stop building this package.
I think we should raise the baseline to include the byte-word
extension (BWX) which I think would be EV56. In addition to
giving some optimisations generally to libc it would eliminate
a class of unaligned access bugs across the archive where gcc
performs an optimisation based on a flawed determination that
certain alignment exists in the memory access of a byte or
16-bit word.
Hello!
On 8/24/21 10:59 PM, Aurelien Jarno wrote:
With the removal of the libc6-xen package in glibc 2.32, the only
package still using the hwcap infrastructure is libc6.1-alphaev67. The hwcap infrastructure consists in upstream support for looking for
libraries in the hwcap directories, plus Debian specific patches to
support disabling hwcap with the /etc/ld.so.nohwcap, plus some mechanism
in the maintainer scripts to disable hwcap support until all libc6
packages are configured.
The various optimized packages have been replaced with time by other mechanisms such as indirect function support (IFUNC), or runtime atomic selection in GCC (-moutline-atomics).
Isn't this type of architecture optimization support currently seeing a revival due to many distributions looking into providing optimized x86_64 variants? [1]
Hi,
On 2021-08-25 13:47, Michael Cree wrote:
On Tue, Aug 24, 2021 at 10:59:32PM +0200, Aurelien Jarno wrote:
I would therefore like to discuss the future of the libc6.1-alphaev67 package on alpha. According to popcon, to take with a grain of salt
given the low number of submissions, this package is installed on 20% of the installations. I wonder if this package is really useful in terms of performance, or if the architecture baseline can be raised to ev67, or
to a ev6 as a compromise. The goal is to stop building this package.
I think we should raise the baseline to include the byte-word
extension (BWX) which I think would be EV56. In addition to
giving some optimisations generally to libc it would eliminate
a class of unaligned access bugs across the archive where gcc
performs an optimisation based on a flawed determination that
certain alignment exists in the memory access of a byte or
16-bit word.
That's really interesting. If raising the baseline to EV56 also helps to eliminate other bugs, it's something worth considering. Do you know if
there is a lot of hardware not compatible with this baseline? Also do
you have an idea if there is a big difference between EV56 and EV67
optimized code?
Therefore the libc6.1-alphaev67 package will be removed from the debian package with glibc 2.37. We can take the opportunity to raise the
baseline if needed.
Hello!
On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote:
Therefore the libc6.1-alphaev67 package will be removed from the debian package with glibc 2.37. We can take the opportunity to raise the
baseline if needed.
I think we agreed on raising it to EV56, didn't we?
On 2023-05-14 22:06, John Paul Adrian Glaubitz wrote:
Hello!
On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote:
Therefore the libc6.1-alphaev67 package will be removed from the debian package with glibc 2.37. We can take the opportunity to raise the baseline if needed.
I think we agreed on raising it to EV56, didn't we?
It was not clear to me from the current thread, but I guess the
discussion have been continued somewhere else.
Could you please take care of raising the baseline at the GCC level? In
the meantime, I'll force -mcpu=ev56 at the glibc level.
Hi Aurelien!
On Sun, 2023-05-14 at 22:47 +0200, Aurelien Jarno wrote:
On 2023-05-14 22:06, John Paul Adrian Glaubitz wrote:
Hello!
On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote:
Therefore the libc6.1-alphaev67 package will be removed from the debian package with glibc 2.37. We can take the opportunity to raise the baseline if needed.
I think we agreed on raising it to EV56, didn't we?
It was not clear to me from the current thread, but I guess the
discussion have been continued somewhere else.
Could you please take care of raising the baseline at the GCC level? In
the meantime, I'll force -mcpu=ev56 at the glibc level.
Yes, absolutely. I will file a bug report against GCC asking for the baseline raise.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 353 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 85:02:09 |
| Calls: | 7,639 |
| Files: | 12,803 |
| Messages: | 5,694,297 |