10:12 a.m.
Wiki ->
https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_A...
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Additional paths will be inserted into the search path used for
executables on systems which have a compatible CPU.
Those additional paths will mirror the AMD64 "microarchitecture
levels" supported by the glibc-hwcaps mechanism: `x86-64-v2`,
`x86-64-v3`, `x86_64-v4`.
Systemd will be modified to insert the additional directories into the
`$PATH` environment variable (affecting all programs on the system)
and the equivalent internal mechanism in `systemd` (affecting what
executables are used by services).
Individual packages can provide optimized libraries via the
glibc-hwcaps mechanism and optimized executables via the extended
search path. This optimized code will be used if the CPU supports it.
''Which'' packages provide the optimized code and at which level will
be made by individual package maintainers based on benchmark results.
== Owner ==
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
NOTE: I'm writing and filling this proposal on the last day allowed
for system-wide proposals. It is too large for one person. If you are
interested, please let me know or even add yourself to the list of
Owners. I would love to have more people working on this.
== Detailed Description ==
Fedora binaries for the AMD64 architecture are compiled with
code-generation flags that support almost all CPU variants. But newer
generations of processors gained additional instructions that may be
used to generate faster code. A vendor-independent x86-64 psABI
supplement defines four "microachitecture levels": `x86-64-v1` (the
baseline, our code targets this), `x86-64-v2` (+`SSE3`, CentoOS
targets this), `x86-64-v3` (+`AVX`), `x86-64-v4` (+`AVX512`) [1]. When
code is compiled for a higher microarchitecture level it will crash
(with `SIGILL`, "illegal instruction") on CPUs which do not support
it. Benchmark results show small differences in performance: usually
in the range from -5% to 10%, with no discernible difference for most
code, but '''some''' applications benefit, with gains of 120% in
some
benchmarks [e.g. 2, 4].
Over the years, various people have expressed interest in raising the
required microarchitecture levels. But we have been very conservative
in making changes, because support is missing in many older CPUs that
are still in use, and in fact, even in some CPUs produced and sold
today. By raising the required level we would make Fedora completely
unusable on many machines. It also seems that recompiling ''all''
packages with the changed options would largely be a waste of
resources, because for most code it makes no difference. But for some
of the numerical or cryptographic code there are noticeable gains and
it seems to be worth the effort to provide optimized code. This also
makes Fedora more attractive to people interested in optimization.
The dynamic linker already has the `glibc-hwcaps` mechanism to load
optimized implementations of ''shared objects'' [3]. This means that
packages can provide optimized libraries and they linker will be
automatically load them from separate directories if appropriate.
(For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
To extend the glibc-hwcaps mechanism to ''executables'', `systemd`
will be modified to extend the search path with appropriate
directories. When started, it will check the CPU capabilities and
modify the executable search path it has internally and which is also
used to set `$PATH` for services. (For AMD64,
`/usr/bin/glibc-hwcaps/x86-64-v{2,3,4}/`.)
Note: the ELF format provides the IFUNC mechanism to dynamically
select a variant of a function (symbol) when an executable is loaded
[5]. This is in particular used to load code using specific CPU
instructions when those are supported. This mechanism is both more
general (because it allows arbitrary selection criteria), more
fine-grained (because there can be other variants than just a few
fixed microarchitecture levels), and more efficient (because only the
parts of the code that benefit from this need to be provided in
multiple variants). In particular, glibc already makes extensive use
of this to provide optimized code, which is then widely used by other
libraries and programs. This means that even though we compile code in
a way where the lowest baseline is supported, modern CPU instructions
are already widely used. This is one of the reasons why compiling for
a higher baseline often doesn't make any difference in benchmarks. The
IFUNC mechanism or an equivalent mechanism should generally be
preferred. Nevertheless, that needs to be implented in the program or
library itself, which is not trivial. The two mechanisms in this
Proposal are intended for the packages which do not support IFUNCs or
some other equivalent mechanism.
[1]
https://hackweek.opensuse.org/all/projects/support-glibc-hwcaps-and-micro...
[2]
https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0002-march...
[3] https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html<...
[4] https://blog.centos.org/2023/08/centos-isa-sig-performance-investigation/...
[5] https://jasoncc.github.io/gnu_gcc_glibc/gnu-ifunc.html<BR>
Glibc-hwcaps together with the new feature in systemd provide a
generic mechanism. It will be up to individual packages to actually
provide code which makes use of it. Individual package maintainers are
encouraged to benchmark their packages after recompilation, and
provide the optimized variants if useful. (I.e. the code in question
is measureably faster '''and''' the program is ran often enough
for
this to make a difference.)
The Change Owners will implement the packaging changes for a few
packages while developing the general mechanism and will submit those
as pull requests. Other maintainers are asked to do the same for their
packages.
Optimized variants of programs and libraries MAY be packaged in a
separate subpackage. The general packaging rules should be applied,
i.e. a separate package or packages SHOULD be created if it is files
are large enough.
Available benchmark results [2,4] are narrow and not very convincing.
We should plan an evaluation of results after one release. If it
turns out that the real gains are too small, we can scrap the effort.
On the other hand, we should also consider other architectures. For
example, microarchitecture levels `z{14,15}` for `s390x` or
`power{9,10}` for `ppc64le`. Other architectures are not included in
this Change Proposal to reduce its scope.
== Feedback ==
== Benefit to Fedora ==
The developers who are interested in this kind of optimization work
can perform it within Fedora, without having to build separate
repositories. The users who have the appropriate hardware will gain
performance benefits. Faster code is also more energy-efficient. The
change will be automatic and transparent to users.
Note that other distributions use higher microarchitecture levels. For
example RHEL 9 uses x86-64-v2 as the baseline, RHEL 10 will use
x86-64-v3, and other distros provide optimized variants (OpenSUSE,
Arch Linux). We implement the same change in Fedora in a way that is
scoped more narrowly, but should provide the same performance and
energy benefits.
== Scope ==
* Proposal owners:
** Extend systemd to set the executable search path using the same
criteria as the dynamic linker.
** Implement packaging changes for at least one package with a library
and at least one package with executables and submit this as pull
requests.
** Provide a pull request for the Packaging Guidelines to describe the
changes listed in Description above.
* Other developers:
** Do benchmarking and implement packaging changes for other packages
if beneficial.
* Release engineering: [https://pagure.io/releng/issue/11864 #11864]
* Policies and guidelines: TBD.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No impact.
== How To Test ==
* Use `/usr/bin/ld.so --help` to check which hwcaps are supported by the system.
* Install one or more packages which provide optimized code.
* Restart the system or re-login to reinitialize `$PATH`.
* Check that appropriate directories are present in `$PATH`.
* Run some benchmarks and check that the optimized code is indeed faster.
== User Experience ==
There should be no impact for users. If the optimized code is
available and installed for their hardware, various tasks may finish
faster and use less energy.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Undo the changes in packages which introduced
them and recompile.
* Contingency deadline: Any time.
* Blocks release? No.
== Documentation ==
== Release Notes ==
Packages which benefit from being compiled for higher AMD64
microarchitecture levels (`x86-64-v2`, `x86-64-v3`, `x86_64-v4`) are
now provided with optimized variants which will be used automatically
on appropriate CPUs. This includes: TBD1, TBD2, TBD3.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
10:58 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
Once upon a time, Aoife Moloney <amoloney(a)redhat.com> said:
Systemd will be modified to insert the additional directories into
the
`$PATH` environment variable (affecting all programs on the system)
Anything that depends on PATH entries is IMHO doomed to failure. There
are way too many things that explicitly set PATH to "known" values (for
good and bad reasons) to be able to depend on extending it. Heck, it
took a long time to get sudo just to include /usr/local/{bin,sbin}.
--
Chris Adams <linux(a)cmadams.net>
11:07 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On 28 Dec 2023, at 16:58, Chris Adams <linux(a)cmadams.net>
wrote:
Anything that depends on PATH entries is IMHO doomed to failure.
Indeed, how would my shell get the right micro architecture into its PATH?
Would konsole on plasma desktop picking up PATH from systemd?
The alternative would be to symlink the "right" version of a program/library
from
the micro architecture dir into /usr/bin and /usr/lib maybe?
Barry
5:42 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On Thu, Dec 28, 2023 at 05:07:09PM +0000, Barry Scott wrote:
> On 28 Dec 2023, at 16:58, Chris Adams <linux(a)cmadams.net> wrote:
>
> Anything that depends on PATH entries is IMHO doomed to failure.
> There are way too many things that explicitly set PATH to "known"
> values (for good and bad reasons) to be able to depend on
> extending it. Heck, it took a long time to get sudo just to
> include /usr/local/{bin,sbin}.
Things that reset $PATH to "known" values are usually breaking things
and doing unnecessary work. It is OK to extend the $PATH by inserting
something (usually at the front), but systemd sets it to something
appropriate on a given system for _everything_ that is started, so
resetting it is not useful.
It was very common to set the $PATH via .bash_profile or other
shell-specific mechanisms. This is flexible and convenient, but the
problem with that approach is that it happens too late: since now the
system may get all the way the graphical interface without going
through a shell, if we want $PATH to be set properly for the whole
environment including service binaries started directly by systemd,
this needs to be done by systemd itself. And once it has done that,
it's not helpful if the shell also plays with $PATH, affecting some
processes but not others.
But yeah, it's possible that sometimes we'll and up with an environment
with $PATH without the additional directories. That's OK: it will
gracefully fall back to the generic versions. Hopefully, people
will fix those environments over time.
(Sudo is a special case: it needs to reset the path to avoid being
influenced by the calling environment. But things started through sudo
are generally not CPU-intenstive, so using the generic versions should
be OK.)
Indeed, how would my shell get the right micro architecture into its
PATH?
Would konsole on plasma desktop picking up PATH from systemd?
Yes. If should already be doing that.
The alternative would be to symlink the "right" version of
a program/library from
the micro architecture dir into /usr/bin and /usr/lib maybe?
The approaches with glibc-hwcaps and the proposed path-based thing for binaries
have the advantage that they are dynamic. The same image can be used on different
machines. It may even be read-only. In particular, in case of VMs, if we stop
the VM, move it to a different host or change it's CPU settings, and restart it,
it'll gracefully DTRT. It also important that the system remains functional
even if a CPU downgrade happens for any reason.
We _could_ take the approach with symlinks. Most likely, this would be handled
via alternatives, i.e. the symlinks would go through /etc, i.e. /usr/bin/foo
→ /etc/alternatives/foo → /usr/lib-something/bin/foo. This is doable, but I
like the dynamic approach much more.
Also, glibc-hwcaps are implemented and available since glibc 2.33.
Combining a static symlink-based system for binaries with a dynamic
path-based system for libraries would be very strange.
Zbyszek
6:29 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On Fri, Dec 29, 2023 at 6:43 AM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl> wrote:
On Thu, Dec 28, 2023 at 05:07:09PM +0000, Barry Scott wrote:
>
>
> > On 28 Dec 2023, at 16:58, Chris Adams <linux(a)cmadams.net> wrote:
> >
> > Anything that depends on PATH entries is IMHO doomed to failure.
> > There are way too many things that explicitly set PATH to "known"
> > values (for good and bad reasons) to be able to depend on
> > extending it. Heck, it took a long time to get sudo just to
> > include /usr/local/{bin,sbin}.
Things that reset $PATH to "known" values are usually breaking things
and doing unnecessary work. It is OK to extend the $PATH by inserting
something (usually at the front), but systemd sets it to something
appropriate on a given system for _everything_ that is started, so
resetting it is not useful.
It was very common to set the $PATH via .bash_profile or other
shell-specific mechanisms. This is flexible and convenient, but the
problem with that approach is that it happens too late: since now the
system may get all the way the graphical interface without going
through a shell, if we want $PATH to be set properly for the whole
environment including service binaries started directly by systemd,
this needs to be done by systemd itself. And once it has done that,
it's not helpful if the shell also plays with $PATH, affecting some
processes but not others.
But yeah, it's possible that sometimes we'll and up with an environment
with $PATH without the additional directories. That's OK: it will
gracefully fall back to the generic versions. Hopefully, people
will fix those environments over time.
(Sudo is a special case: it needs to reset the path to avoid being
influenced by the calling environment. But things started through sudo
are generally not CPU-intenstive, so using the generic versions should
be OK.)
> Indeed, how would my shell get the right micro architecture into its
PATH?
> Would konsole on plasma desktop picking up PATH from systemd?
Yes. If should already be doing that.
> The alternative would be to symlink the "right" version of a
program/library from
> the micro architecture dir into /usr/bin and /usr/lib maybe?
The approaches with glibc-hwcaps and the proposed path-based thing for
binaries
have the advantage that they are dynamic. The same image can be used on
different
machines. It may even be read-only. In particular, in case of VMs, if we
stop
the VM, move it to a different host or change it's CPU settings, and
restart it,
it'll gracefully DTRT. It also important that the system remains functional
even if a CPU downgrade happens for any reason.
We _could_ take the approach with symlinks. Most likely, this would be
handled
via alternatives, i.e. the symlinks would go through /etc, i.e.
/usr/bin/foo
→ /etc/alternatives/foo → /usr/lib-something/bin/foo. This is doable, but I
like the dynamic approach much more.
Also, glibc-hwcaps are implemented and available since glibc 2.33.
Combining a static symlink-based system for binaries with a dynamic
path-based system for libraries would be very strange.
On a philosophical note, I once worked on Apollo workstations. These
could switch
behavior between sysv and bsd unix. To do this, the kernel
would interpret e.g. /usr/bin/$arch, substituting the env variable arch.
At least that is my recollection of how this worked. Elegant I think, but
some might see this as a security problem.
9:27 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On Fri, Dec 29, 2023 at 12:31 PM Neal Becker <ndbecker2(a)gmail.com> wrote:
On a philosophical note, I once worked on Apollo workstations. These could switch
behavior between sysv and bsd unix. To do this, the kernel would interpret e.g.
/usr/bin/$arch, substituting the env variable arch. At least that is my recollection of
how this worked. Elegant I think, but some might see this as a security problem.
The AFS file system has a similar approach for
its sysname, where the special value @sys is
substituted by the kernel for files in that filesystem.
A common way it was used was that something
like /usr/local/bin was a symlink to /usr/local/.@sys/bin
and the @sys variable would contain the architecture
(and/or OS variant) redirect. The @sys value can
contain a list of values to search for existence
(exposed in /proc/fs/afs/sysname). On x86_64
I believe the default is amd64_linux26 (for
historical reasons).
For some large (often HPC) sites, which can have
multiple system architectures and OS variants,
having one common file system with software
and libraries which can be selected by the
client systems sysname "flavor" is valuable.
11:39 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
Once upon a time, Gary Buhrmaster <gary.buhrmaster(a)gmail.com> said:
The AFS file system has a similar approach for
its sysname, where the special value @sys is
substituted by the kernel for files in that filesystem.
The DEC Alpha Unix cluster version of AdvFS had something similar, where
symlinks containing '/{memb}/' were expanded to '/memberX/' where X was
the numeric node ID (needed for lots of config because the cluster
system used a "single root" filesystem, where all members had access to
the shared storage and mounted the same volume as /).
--
Chris Adams <linux(a)cmadams.net>
11:25 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On 12/28/23 12:58 PM, Chris Adams wrote:
Once upon a time, Aoife Moloney <amoloney(a)redhat.com> said:
> Systemd will be modified to insert the additional directories into the
> `$PATH` environment variable (affecting all programs on the system)
Anything that depends on PATH entries is IMHO doomed to failure. There
are way too many things that explicitly set PATH to "known" values (for
good and bad reasons) to be able to depend on extending it. Heck, it
took a long time to get sudo just to include /usr/local/{bin,sbin}.
Maybe replacing the /usr/bin related entries with a generic wrapper that
launch the best binary from the per architecture directories.
Note: This may affect a few programs that use argv[0] for something
meaningful.
2:27 a.m.
Il 28/12/23 18:25, Robert Marcano via devel ha scritto:
On 12/28/23 12:58 PM, Chris Adams wrote:
> Once upon a time, Aoife Moloney <amoloney(a)redhat.com> said:
>> Systemd will be modified to insert the additional directories into the
>> `$PATH` environment variable (affecting all programs on the system)
> Anything that depends on PATH entries is IMHO doomed to failure. There
> are way too many things that explicitly set PATH to "known" values (for
> good and bad reasons) to be able to depend on extending it. Heck, it
> took a long time to get sudo just to include /usr/local/{bin,sbin}.
>
Maybe replacing the /usr/bin related entries with a generic wrapper that
launch the best binary from the per architecture directories.
Note: This may affect a few programs that use argv[0] for something
meaningful.
--
I've got not much knowledge on this matter, anyway here's my 2c:
Since we're talking about a few packages that will gain from this change
and that they're must be manually "enabled" to build with this feature,
I'd prefer this kind of wrapper approach instead of changing the PATH
globally.
Maybe a RPM macro could be provided for using in specfile where we want
optimized binaries. Those binaries will be created like 'xz-x86-64-v2',
'xz-x86-64-v3' and so on and all installed in /usr/bin. Then a 'xz'
wrapper will call the appropriate executable based on what supported
instruction set is detected available. And maybe in future we could have
dnf to install the appropriate optimized subpackage binaries.
It may be much more complex than just injecting new PATHs, but I think
it's more elegant and could be a shared mechanism with other linux
distributions.
Mattia
9:20 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On Sat, Dec 30, 2023 at 08:27:46AM +0000, Mattia Verga via devel wrote:
Il 28/12/23 18:25, Robert Marcano via devel ha scritto:
> On 12/28/23 12:58 PM, Chris Adams wrote:
>> Once upon a time, Aoife Moloney <amoloney(a)redhat.com> said:
>>> Systemd will be modified to insert the additional directories into the
>>> `$PATH` environment variable (affecting all programs on the system)
>> Anything that depends on PATH entries is IMHO doomed to failure. There
>> are way too many things that explicitly set PATH to "known" values
(for
>> good and bad reasons) to be able to depend on extending it. Heck, it
>> took a long time to get sudo just to include /usr/local/{bin,sbin}.
>>
> Maybe replacing the /usr/bin related entries with a generic wrapper that
> launch the best binary from the per architecture directories.
>
> Note: This may affect a few programs that use argv[0] for something
> meaningful.
> --
I've got not much knowledge on this matter, anyway here's my 2c:
Since we're talking about a few packages that will gain from this change
and that they're must be manually "enabled" to build with this feature,
I'd prefer this kind of wrapper approach instead of changing the PATH
globally.
This is also a valid approach. This is the first alternative proposal
which makes me say "hmm, this would also work". It is possibly even
simpler than setting the $PATH. A very small disadvantage is that the
wrapper would need to do its work every time the binary is called.
But the wrapper could be trivially implemented in shell or it could be
a compiled binary, making the wrapper very cheap.
Hmm, what do other people think?
Maybe a RPM macro could be provided for using in specfile where we
want
optimized binaries. Those binaries will be created like 'xz-x86-64-v2',
'xz-x86-64-v3' and so on and all installed in /usr/bin. Then a 'xz'
wrapper will call the appropriate executable based on what supported
instruction set is detected available.
xYes.
And maybe in future we could have
dnf to install the appropriate optimized subpackage binaries.
I didn't cover this in my proposal because it seemed a bit premature
to figure out a way to install variants automatically even before we
know if and how many of those we will have.
My general idea was to have an anchor package like "system-x86-64-v3"
(name to be figured out) and then use rich dependencies to pull in
the -v2 and -v3 variants on systems which have it installed.
Either the user or the installer would only need to install the
right anchor packages and then the rest would be handled automatically
by dnf.
It may be much more complex than just injecting new PATHs, but I
think
it's more elegant and could be a shared mechanism with other linux
distributions.
The mechanism with $PATH would also be shared with other distros.
If the code is added in systemd, it would become automatically
available everywhere.
Zbyszek
7:42 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
This is also a valid approach. This is the first alternative
proposal
which makes me say "hmm, this would also work". It is possibly even
simpler than setting the $PATH. A very small disadvantage is that the
wrapper would need to do its work every time the binary is called.
But the wrapper could be trivially implemented in shell or it could be
a compiled binary, making the wrapper very cheap.
Hmm, what do other people think?
With my computer user hat on, I would much prefer this approach. If
the supposed "dozen" of relevant packages can be built with several
binaries variants, then let's pack them all in the same RPM and use
this mechanism. I'm sure that if successful it would extend to more
packages, including packages on the critical path. I'm fine with that
eventual outcome with this scheme.
This way, if I ever need to take my drive out of a fried laptop and
USB-boot from it on my spare laptop from 2013, then I'm not painting
myself into a corner with binaries too recent for that hardware. I was
happy to be able to do that last summer, and hope to still be able to
in the future (but also hope not to ever need it again). And yes,
Fedora (Xfce) works just fine on that decade-old laptop.
For a wrapper I would be in favor of a shell script, it makes things
much easier to understand as an end user, and it can be installed
once, for example:
ls -l /usr/bin/cp
lrwxrwxrwx. 1 root root 26 Jan 1 00:00 /usr/bin/cp -> /usr/libexec/uarch-exec.sh
On the condition of course that the generic binary is always present,
which shouldn't be difficult if all variants are in the same package
in the first place. In theory there should be less moving parts, but
the difference between theory and reality...
My 2 cents
6:07 p.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On Tue, Jan 16, 2024 at 2:43 PM Dridi Boukelmoune
<dridi.boukelmoune(a)gmail.com> wrote:
> This is also a valid approach. This is the first alternative proposal
> which makes me say "hmm, this would also work". It is possibly even
> simpler than setting the $PATH. A very small disadvantage is that the
> wrapper would need to do its work every time the binary is called.
> But the wrapper could be trivially implemented in shell or it could be
> a compiled binary, making the wrapper very cheap.
>
> Hmm, what do other people think?
With my computer user hat on, I would much prefer this approach. If
the supposed "dozen" of relevant packages can be built with several
binaries variants, then let's pack them all in the same RPM and use
this mechanism. I'm sure that if successful it would extend to more
packages, including packages on the critical path. I'm fine with that
eventual outcome with this scheme.
This way, if I ever need to take my drive out of a fried laptop and
USB-boot from it on my spare laptop from 2013, then I'm not painting
myself into a corner with binaries too recent for that hardware. I was
happy to be able to do that last summer, and hope to still be able to
in the future (but also hope not to ever need it again). And yes,
Fedora (Xfce) works just fine on that decade-old laptop.
But ... you would be able to do this if the proposal was implemented
as-is, as well?
The "non-optimized" variant would still be installed, and PATH would
be set appropriately to fall back to it if you stick the hard drive
into an old machine
(unless I misunderstand the proposal, or your argument here).
Just to give my 2¢ here as well, I was skeptical about the "systemd
sets the $PATH appropriately for the hardware it's booting on", but I
actually like that approach now. Using symbolic links smells too much
like using alternatives, and those have always been a bit brittle.
Fabio
10:58 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On 12/28/23 1:25 PM, Robert Marcano wrote:
On 12/28/23 12:58 PM, Chris Adams wrote:
> Once upon a time, Aoife Moloney <amoloney(a)redhat.com> said:
>> Systemd will be modified to insert the additional directories into the
>> `$PATH` environment variable (affecting all programs on the system)
>
> Anything that depends on PATH entries is IMHO doomed to failure. There
> are way too many things that explicitly set PATH to "known" values (for
> good and bad reasons) to be able to depend on extending it. Heck, it
> took a long time to get sudo just to include /usr/local/{bin,sbin}.
>
Maybe replacing the /usr/bin related entries with a generic wrapper that
launch the best binary from the per architecture directories.
Note: This may affect a few programs that use argv[0] for something
meaningful.
The more I think about this, I am more convinced that /usr/bin installed
binaries must do this redirection too even in the case the PATH is
modified as this proposal states.
What about programs intentionally use absolute paths? These programs
will not take advantage of the optimizations of the binary they are
trying to start.
There many reasons for sometimes using an absolute path is agood idea, like:
1. Security: avoid depending on a PATH that can be user manipulated.
2. Configuration files that allow to switch to alternate implementation
of the tool they call. I found a few on my installation, and their
defaults include /usr/bin absolute paths.
3. Programs that run inside PATH is reset for security like sudo,
CGI-BIN, etc.
Notice this PATH based optimization will only work when callers invoke
the program by name only, relative paths will not get optimized either,
a rare case but it could happen.
12:19 p.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On 1/19/24 12:58 PM, Robert Marcano wrote:
On 12/28/23 1:25 PM, Robert Marcano wrote:
> On 12/28/23 12:58 PM, Chris Adams wrote:
>> Once upon a time, Aoife Moloney <amoloney(a)redhat.com> said:
>>> Systemd will be modified to insert the additional directories into the
>>> `$PATH` environment variable (affecting all programs on the system)
>>
>> Anything that depends on PATH entries is IMHO doomed to failure. There
>> are way too many things that explicitly set PATH to "known" values
(for
>> good and bad reasons) to be able to depend on extending it. Heck, it
>> took a long time to get sudo just to include /usr/local/{bin,sbin}.
>>
>
> Maybe replacing the /usr/bin related entries with a generic wrapper
> that launch the best binary from the per architecture directories.
>
> Note: This may affect a few programs that use argv[0] for something
> meaningful.
The more I think about this, I am more convinced that /usr/bin installed
binaries must do this redirection too even in the case the PATH is
modified as this proposal states.
What about programs intentionally use absolute paths? These programs
will not take advantage of the optimizations of the binary they are
trying to start.
There many reasons for sometimes using an absolute path is agood idea,
like:
1. Security: avoid depending on a PATH that can be user manipulated.
2. Configuration files that allow to switch to alternate implementation
of the tool they call. I found a few on my installation, and their
defaults include /usr/bin absolute paths.
3. Programs that run inside PATH is reset for security like sudo,
CGI-BIN, etc.
Notice this PATH based optimization will only work when callers invoke
the program by name only, relative paths will not get optimized either,
a rare case but it could happen.
I have a counter proposal without modifying $PATH:
With the already defined directories
/usr/bin/glibc-hwcaps/x86-64-v{2,3,4}/ add two new ones:
/usr/bin/glibc-hwcaps/x86-64
/usr/bin/glibc-hwcaps/x86-64-dynamic
Applications with optimized binaries will continue to install them on
/usr/bin/glibc-hwcaps/x86-64-v{2,3,4}/ but the non optimized version
isn't installed on /usr/bin but on /usr/bin/glibc-hwcaps/x86-64.
/usr/bin/glibc-hwcaps/x86-64-dynamic will be a read only overlayfs
mounted by systemd, stacked with x86-64v4 on top and x86-64 on the bottom.
There will not be /usr/bin binaries for the optimized packages but
symlinks to /usr/bin/glibc-hwcaps/x86-64-dynamic
Advantages for systemd based environment:
1. The optimized binaries are available to all the system, without
worrying about applications that reset $PATH, or executions by relative
or absolute paths and not only by name.
2. Imagine if and application like Firefox (only an example) get a boost
by having the main binary optimized. /usr/bin/firefox currently is a
shell script, there is no way optimize it with the current proposal,
only if the script duplicates the microachitecture selection logic. With
this proposal, modifying /usr/lib64/firefox/firefox to point to
/usr/bin/glibc-hwcaps/x86-64-dynamic/firefox could work to. In reality
it can work for all binaries outside of $PATH.
There are two downsides I could find:
1. Fedora Container images must be build with
/usr/bin/glibc-hwcaps/x86-64-dynamic being a symlink to
/usr/bin/glibc-hwcaps/x86-64 in order to non optimized binaries to be
the default. This current proposal doesn't optimize either for
containers runtimes that don't run systemd inside the container. Maybe
in the future if this kind of layout get adoption on other
distributions, container runtimes could do the overlay mount by themselves
2. In the case of trying to rescue the system, the process to create a
chroot from the installation media will need and extra bind mount for
/usr/bin/glibc-hwcaps/x86-64-dynamic pointing to
/usr/bin/glibc-hwcaps/x86-64
Note aside: I think that the Live CD image should get an script
available that do the same rescue boot option when trying to build the
disk tree on /mnt/sysimage, if that script were available on LiveCD,
rescue operations would be easier.
3:18 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On 1/19/24 18:58, Robert Marcano via devel wrote:
On 12/28/23 1:25 PM, Robert Marcano wrote:
> On 12/28/23 12:58 PM, Chris Adams wrote:
>> Once upon a time, Aoife Moloney <amoloney(a)redhat.com> said:
>>> Systemd will be modified to insert the additional directories into the
>>> `$PATH` environment variable (affecting all programs on the system)
>>
>> Anything that depends on PATH entries is IMHO doomed to failure. There
>> are way too many things that explicitly set PATH to "known" values
(for
>> good and bad reasons) to be able to depend on extending it. Heck, it
>> took a long time to get sudo just to include /usr/local/{bin,sbin}.
>>
>
> Maybe replacing the /usr/bin related entries with a generic wrapper
> that launch the best binary from the per architecture directories.
>
> Note: This may affect a few programs that use argv[0] for something
> meaningful.
The more I think about this, I am more convinced that /usr/bin installed
binaries must do this redirection too even in the case the PATH is
modified as this proposal states.
What about programs intentionally use absolute paths? These programs
will not take advantage of the optimizations of the binary they are
trying to start.
There many reasons for sometimes using an absolute path is agood idea,
like:
1. Security: avoid depending on a PATH that can be user manipulated.
2. Configuration files that allow to switch to alternate implementation
of the tool they call. I found a few on my installation, and their
defaults include /usr/bin absolute paths.
3. Programs that run inside PATH is reset for security like sudo,
CGI-BIN, etc.
Notice this PATH based optimization will only work when callers invoke
the program by name only, relative paths will not get optimized either,
a rare case but it could happen.
+100 to this.
Using something path-based will also exclude EVERYTHING started with a
shebang. I guess we didn't want to optimize those
Python/Perl/Ruby/whatnot scripts here?
A path based approach isn't anywhere near worth the mess it creates. A
humble opinion.
- Panu -
5:34 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
* Panu Matilainen:
Using something path-based will also exclude EVERYTHING started with
a
shebang. I guess we didn't want to optimize those
Python/Perl/Ruby/whatnot scripts here?
A path based approach isn't anywhere near worth the mess it creates. A
humble opinion.
I'm not sure if it's necessary. Most script interpreters (so things
that are typically used with shebangs) live in DSOs now, so they
wouldn't need the path-based optimization anyway.
Thanks,
Florian
6:23 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture
(System-Wide)
How much waste is it to recompile all the packages?
The whole proposal sounds like a big hack from beginning to the end.
Fragile setup with $PATH, complicated SPEC files, complicate the %build part.
In order to reduce build time that have not been quantified.
3:08 p.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On Fri, Dec 29, 2023 at 12:23:23PM -0000, Jonny Heggheim wrote:
How much waste is it to recompile all the packages?
The whole proposal sounds like a big hack from beginning to the end.
Fragile setup with $PATH, complicated SPEC files, complicate the %build part.
I disagree that the setup of $PATH is fragile. We have clean mechanisms
to set it, and if those mechanisms are broken somewhere, fixing them
is something that we should do anyway, making the whole system better.
The spec files will be more complicated, that is true. But I very
much prefer a bit of complexity in a small set of packages than
a "clean" solution that requires significant resource investment
from releng and other places.
At this point we don't even know if the whole thing will deliver the
benefits that are expected. Doing the maximalist solution right now
would be putting the cart before the horse.
In order to reduce build time that have not been quantified.
Building packages with a different set of flags would be equivalent in
terms of resource consumption to an additional architecture.
We currently have x86_64, arm64, s390x, ppc64el (*), so a new
microarchitecture variant would be ~25% more cost (for archful packages).
But building packages is just one thing. Those packages would need
to be distributed, causing additional load on mirrors and archives.
Our mirrors would not be keen on seeing this increase.
And then there's a question of how those packages would be consumed:
firstly, the installer would need to be modified to pick the variant
at installation time, and secondly, such an installation could never
be used with a different CPU, the initial choice would be locked in.
The benchmarks that were linked in the Change Propoposal show that
it's a small minority of packages that show potential gains. I really
don't expect that we'll end up with more than a few dozen packages
where this turns out to be useful. Doing that within the existing
architecture is much much cheaper than adding a new architecture
variant.
The proposed scheme is also more flexible: for example, x86-64-v3 may be
great for some cryptotools, but v4 might be required to gain a good
result for some codecs. Adding _multiple_ separate architectures
is out of the question, but having some packages with two, three,
or even four microarchitecture subpackages is no biggie.
Zbyszek
3:20 p.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> said:
But building packages is just one thing. Those packages would need
to be distributed, causing additional load on mirrors and archives.
Our mirrors would not be keen on seeing this increase.
You're adding binaries, so you're either increasing the size of existing
packages or adding alternate packages. The size increase will be there
either way; the difference is that with separate packages, not everybody
will be downloading all the content (so easier on the mirrors than just
bigger packages containing multiple binaries).
So if distribution is a concern, separate packages is a plus, not a
minus.
And then there's a question of how those packages would be
consumed:
firstly, the installer would need to be modified to pick the variant
at installation time, and secondly, such an installation could never
be used with a different CPU, the initial choice would be locked in.
It's not like we haven't had this before. Yes, it was annoying, but it
wasn't THAT big of an issue.
--
Chris Adams <linux(a)cmadams.net>
10:10 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On Fri, Dec 29, 2023 at 03:20:45PM -0600, Chris Adams wrote:
Once upon a time, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> said:
> But building packages is just one thing. Those packages would need
> to be distributed, causing additional load on mirrors and archives.
> Our mirrors would not be keen on seeing this increase.
You're adding binaries, so you're either increasing the size of existing
packages or adding alternate packages. The size increase will be there
either way; the difference is that with separate packages, not everybody
will be downloading all the content (so easier on the mirrors than just
bigger packages containing multiple binaries).
So if distribution is a concern, separate packages is a plus, not a
minus.
We don't have a mechanism in dnf/rpm to mix & match, i.e. to select
from one microarchitecture if available and from a different one
otherwise. So if we were to provide e.g. a -v2 variant, then it'd
have to provide _all_ packages.
In the proposed scheme, we only provide additional packages for select
packages.
> And then there's a question of how those packages would be
consumed:
> firstly, the installer would need to be modified to pick the variant
> at installation time, and secondly, such an installation could never
> be used with a different CPU, the initial choice would be locked in.
It's not like we haven't had this before. Yes, it was annoying, but it
wasn't THAT big of an issue.
There is certainly more than one way to skin this particular cat.
I don't expect most users to know which microarchitectures are supported
by their CPU. We are always trying to make the installer as simple as
possible so we shouldn't add a very complex technical question.
One of the advantages of the proposed scheme is that we should be able
to make it work transparently and automatically for the end users.
I know that my approach is different then what other distros have
tried: CentoOS/RHEL simply upgraded to a higher baseline and lost
support for some CPUs, OpenSUSE/Ubuntu/Arch provide alternative repos
which need to be explicitly selected by users. If the proposal gets
accepted, we will be able to compare.
Zbyszek
4:52 p.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
Additional paths will be inserted into the search path used for
executables on systems which have a compatible CPU.
Searching $PATH is a slow operation. It is so slow that a shell script
which typically processes many files using utilities from packages
coreutils and/or binutils often factors-out the PATH search by using
shell variables:
CP=$(which cp)
...
$(CP) $file.in $file.out
Do not add directories to $PATH. Any executable which may benefit
significantly from micro-architectural enhancements should use
the IFUNC mechanism explicitly. If the developer of the executable
cannot be bothered to use IFUNC, then the uses of the executable
should not slow down EVERY shell path search in the entire session.
Glibc already uses IFUNC for many mem*() and str*() functions (such as
memcpy, strlen, etc.), which covers the vast majority of "random"
cases which usually benefit from such microarchitecture enhancements.
Fedora binaries for the AMD64 architecture are compiled with
code-generation flags that support almost all CPU variants. But newer
generations of processors gained additional instructions that may be
used to generate faster code. A vendor-independent x86-64 psABI
supplement defines four "microachitecture levels": `x86-64-v1` (the
baseline, our code targets this), `x86-64-v2` (+`SSE3`, CentoOS
targets this), `x86-64-v3` (+`AVX`[edit: and + 'AVX2']), `x86-64-v4` (+`AVX512`)
[1].
Please note the edit: -v3 includes both AVX and AVX2.
There are x86_64 CPUs which have AVX (128-bit xmm registers) but not
AVX2 (256-bit ymm registers): for instance, AMD A10-7890K (cpu family
21, model 56: 4 CPU cores, 8 graphics cores), which was current in 2019.
Why is there no corresponding microarchitecure level? In many cases
AVX2 provides significant benefit over AVX, without the monstrosity
of AVX512 (512-bit zmm registers) which requires vastly more chip area
and power consumption.
8:27 p.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
John Reiser wrote on Sun, Dec 31, 2023 at 02:52:53PM -0800:
> Additional paths will be inserted into the search path used for
> executables on systems which have a compatible CPU.
Searching $PATH is a slow operation. It is so slow that a shell script which
typically processes many files using utilities from packages coreutils
and/or binutils often factors-out the PATH search by using
shell variables:
CP=$(which cp)
...
$(CP) $file.in $file.out
(getting slighly off topic, sorry)
That hasn't been needed for as long as I've used a compter, all^W most
shells already do this for you.
(It's obvious in interactive mode when you need to use hash/rehash
built-ins after moving a binary that you ran once, but it's true as well
when running scripts: if you e.g. strace for stat() calls a script that
calls cp twice you'll see it only looks through PATH once. This is true
of at least bash, zsh, dash, and even busybox ash... Interestingly fish
doesn't seem to do it, I'm a bit surpised here)
Anyway, I'm not arguing PATH lookups are fast -- having seen some setups
with 'module's over NFS or networked file systems I know how bad that
can get -- just don't undersell your shells :)
--
Dominique Martinet | Asmadeus
9:54 p.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On 12/31/23 18:27, Dominique Martinet wrote:
John Reiser wrote on Sun, Dec 31, 2023 at 02:52:53PM -0800:
>> Additional paths will be inserted into the search path used for
>> executables on systems which have a compatible CPU.
>
> Searching $PATH is a slow operation. It is so slow that a shell script which
> typically processes many files using utilities from packages coreutils
> and/or binutils often factors-out the PATH search by using
> shell variables:
>
> CP=$(which cp)
> ...
> $(CP) $file.in $file.out
(getting slighly off topic, sorry)
That hasn't been needed for as long as I've used a compter, all^W most
shells already do this for you.
(It's obvious in interactive mode when you need to use hash/rehash
built-ins after moving a binary that you ran once, but it's true as well
when running scripts: if you e.g. strace for stat() calls a script that
calls cp twice you'll see it only looks through PATH once. This is true
of at least bash, zsh, dash, and even busybox ash... Interestingly fish
doesn't seem to do it, I'm a bit surpised here)
Some programs DO search $PATH because they use execlp() or
execvp() or execvpe(). Example of /usr/bin/rpm searching for "sh":
===== [edited for clarity]
$ echo $PATH
/A:/B:/usr/local/bin:/usr/bin: ...
$ strace -f -e trace=newfstatat rpm --install -p zip-3.0-37.fc38.src.rpm
19792 newfstatat(AT_FDCWD, "/A/sh", 0x7fff8c204840, 0) = -1 ENOENT
19792 newfstatat(AT_FDCWD, "/B/sh", 0x7fff8c204840, 0) = -1 ENOENT
19792 newfstatat(AT_FDCWD, "/usr/local/bin/sh", 0x7fff8c204840, 0) = -1
ENOENT
19792 newfstatat(AT_FDCWD, "/usr/bin/sh", ...}, 0) = 0
=====
That's with rpm-4.18.2-1.fc38.x86_64 and glibc-2.37-16.fc38.x86_64.
5:20 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
The dynamic linker already has the `glibc-hwcaps` mechanism to load
optimized implementations of ''shared objects'' [3]. This means that
packages can provide optimized libraries and they linker will be
automatically load them from separate directories if appropriate.
(For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
Is this something specific to x86_64 that the libs needs to be nested in
a place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use
e.g. `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more
universal.
Vít
6:42 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On Tue, 2 Jan 2024 at 06:21, Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
The dynamic linker already has the `glibc-hwcaps` mechanism to load
optimized implementations of ''shared objects'' [3]. This means that
packages can provide optimized libraries and they linker will be
automatically load them from separate directories if appropriate.
(For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
Is this something specific to x86_64 that the libs needs to be nested in a
place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g.
`/usr/x86-64-v{2,3,4}/lib`
directories instead? Or something more universal.
Adding directories to the /usr sub-space generally gets bogged down into
'You are polluting my name-space' arguments which get no-where because some
of the people getting angry is having to live with some 3rd party rules and
regulations which stipulated how things look and will only get updated once
a decade or so. [The same goes with subdirectories in /usr/bin etc where it
causes similar problems.] There tends to be no 'general' case which works
unless it gets 'agreed' upon by some outside of the distro body that
publishes 'versioned' standards.
Vít
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
9:23 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a):
On Tue, 2 Jan 2024 at 06:21, Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
> The dynamic linker already has the `glibc-hwcaps` mechanism to load
> optimized implementations of ''shared objects'' [3]. This means
that
> packages can provide optimized libraries and they linker will be
> automatically load them from separate directories if appropriate.
> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
>
Is this something specific to x86_64 that the libs needs to be
nested in a place such as
`/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g.
`/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more
universal.
Adding directories to the /usr sub-space generally gets bogged down
into 'You are polluting my name-space' arguments which get no-where
because some of the people getting angry is having to live with some
3rd party rules and regulations which stipulated how things look and
will only get updated once a decade or so. [The same goes with
subdirectories in /usr/bin etc where it causes similar problems.]
There tends to be no 'general' case which works unless it gets
'agreed' upon by some outside of the distro body that publishes
'versioned' standards.
Checking what Debian does, they have paths such as
`/usr/lib/x86_64-linux-gnu/`. So we would not be alone.
Vít
Vít
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
--
_______________________________________________
devel mailing list --devel(a)lists.fedoraproject.org
To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedora...
Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
9:52 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On Tue, 2 Jan 2024 at 10:24, Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a):
On Tue, 2 Jan 2024 at 06:21, Vít Ondruch <vondruch(a)redhat.com> wrote:
>
> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
>
> The dynamic linker already has the `glibc-hwcaps` mechanism to load
> optimized implementations of ''shared objects'' [3]. This means that
> packages can provide optimized libraries and they linker will be
> automatically load them from separate directories if appropriate.
> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
>
>
>
> Is this something specific to x86_64 that the libs needs to be nested in
> a place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use
> e.g. `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more
> universal.
>
>
Adding directories to the /usr sub-space generally gets bogged down into
'You are polluting my name-space' arguments which get no-where because some
of the people getting angry is having to live with some 3rd party rules and
regulations which stipulated how things look and will only get updated once
a decade or so. [The same goes with subdirectories in /usr/bin etc where it
causes similar problems.] There tends to be no 'general' case which works
unless it gets 'agreed' upon by some outside of the distro body that
publishes 'versioned' standards.
Checking what Debian does, they have paths such as
`/usr/lib/x86_64-linux-gnu/`. So we would not be alone.
Do they have /usr/bin/{arch} directories also? I thought they did the
/usr/lib/{arch-os-type}/ for libraries to deal with multiarch (aka x86_32,
x86_64, etc) libs . the main item will be if we are following
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s04.html or if there
is enough variation in
https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html
to allow subdirectories in /usr/bin.
It would seem that in the freedesktop version /usr/lib/{arch-id} is
acceptable and I think in the FHS-3.0, then /usr/lib{qualifier} is ok.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
2:07 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
Note that mingw-* packages currently in Fedora install into the
/usr/i686-w64-mingw32/ or /usr/x86_64-w64-mingw32/ directories.
This is a different topic but if each archful package installed its
files into a directory containing the arch name, it would allow parallel
installability without configuring dnf and possibly make it more
convenient for cross-platform development.
On 2. 1. 2024 16:23, Vít Ondruch wrote:
Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a):
>
>
> On Tue, 2 Jan 2024 at 06:21, Vít Ondruch <vondruch(a)redhat.com> wrote:
>
>
> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
>> The dynamic linker already has the `glibc-hwcaps` mechanism to load
>> optimized implementations of ''shared objects'' [3]. This
means that
>> packages can provide optimized libraries and they linker will be
>> automatically load them from separate directories if appropriate.
>> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
>>
>
> Is this something specific to x86_64 that the libs needs to be
> nested in a place such as
> `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g.
> `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more
> universal.
>
>
> Adding directories to the /usr sub-space generally gets bogged down
> into 'You are polluting my name-space' arguments which get no-where
> because some of the people getting angry is having to live with some
> 3rd party rules and regulations which stipulated how things look and
> will only get updated once a decade or so. [The same goes with
> subdirectories in /usr/bin etc where it causes similar problems.]
> There tends to be no 'general' case which works unless it gets
> 'agreed' upon by some outside of the distro body that publishes
> 'versioned' standards.
Checking what Debian does, they have paths such as
`/usr/lib/x86_64-linux-gnu/`. So we would not be alone.
Vít
> Vít
>
> --
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard
> battle. -- Ian MacClaren
>
> --
> _______________________________________________
> devel mailing list --devel(a)lists.fedoraproject.org
> To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedora...
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
devel mailing list --devel(a)lists.fedoraproject.org
To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedora...
Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
--
Marián Konček
2:55 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
Thanks for pointing this out.
This reminds me and I don't think this have been discussed yet, but I
guess that we should soon address where e.g. WebAssembly binaries should
go. I think we should really consider to establish some generic
infrastructure for such cases.
Vít
Dne 03. 01. 24 v 9:07 Marián Konček napsal(a):
Note that mingw-* packages currently in Fedora install into the
/usr/i686-w64-mingw32/ or /usr/x86_64-w64-mingw32/ directories.
This is a different topic but if each archful package installed its
files into a directory containing the arch name, it would allow
parallel installability without configuring dnf and possibly make it
more convenient for cross-platform development.
On 2. 1. 2024 16:23, Vít Ondruch wrote:
>
>
> Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a):
>>
>>
>> On Tue, 2 Jan 2024 at 06:21, Vít Ondruch <vondruch(a)redhat.com> wrote:
>>
>>
>> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
>>> The dynamic linker already has the `glibc-hwcaps` mechanism to load
>>> optimized implementations of ''shared objects'' [3]. This
means that
>>> packages can provide optimized libraries and they linker will be
>>> automatically load them from separate directories if appropriate.
>>> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
>>>
>>
>> Is this something specific to x86_64 that the libs needs to be
>> nested in a place such as
>> `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g.
>> `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something
>> more universal.
>>
>>
>> Adding directories to the /usr sub-space generally gets bogged down
>> into 'You are polluting my name-space' arguments which get no-where
>> because some of the people getting angry is having to live with some
>> 3rd party rules and regulations which stipulated how things look and
>> will only get updated once a decade or so. [The same goes with
>> subdirectories in /usr/bin etc where it causes similar problems.]
>> There tends to be no 'general' case which works unless it gets
>> 'agreed' upon by some outside of the distro body that publishes
>> 'versioned' standards.
>
>
> Checking what Debian does, they have paths such as
> `/usr/lib/x86_64-linux-gnu/`. So we would not be alone.
>
>
> Vít
>
>
>> Vít
>>
>> --
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines:
>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>>
>>
>> --
>> Stephen Smoogen, Red Hat Automotive
>> Let us be kind to one another, for most of us are fighting a hard
>> battle. -- Ian MacClaren
>>
>> --
>> _______________________________________________
>> devel mailing list --devel(a)lists.fedoraproject.org
>> To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
>> Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedora...
>> Do not reply to spam, report
it:https://pagure.io/fedora-infrastructure/new_issue
>
> --
> _______________________________________________
> devel mailing list --devel(a)lists.fedoraproject.org
> To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
> Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedora...
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
--
Marián Konček
--
_______________________________________________
devel mailing list --devel(a)lists.fedoraproject.org
To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedora...
Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
6:01 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture
(System-Wide)
On Wednesday, 3 January 2024 10:07:02 IST Marián Konček wrote:
Note that mingw-* packages currently in Fedora install into the
/usr/i686-w64-mingw32/ or /usr/x86_64-w64-mingw32/ directories.
This is a different topic but if each archful package installed its
files into a directory containing the arch name, it would allow parallel
installability without configuring dnf and possibly make it more
convenient for cross-platform development.
This is very similar to Debian's Multiarch[1], but they have
/usr/lib/<arch-tuple> (less pollution of top-level /usr)
Indeed, such organization is ideal for cross-platform development:
* Libraries are installed in the same path, both for native and for cross
compilation
* As a result, normal packages in the distribution already have the libraries in the
correct locations for both native/cross compilation
* The packaging system (APT) was adapted to allow co-installation of such packages
(since the files don't conflict)
* At a later stage, the distribution began shipping complete toolchains for all
supported architectures -- built from exactly the same source (same gcc, same binutils,
etc.)
* I.e: a developer that need cross-compilation, install the wanted toolchain(s) and
all library packages are immediately available from standard repositories.
I guess Fedora people that work on ARM/ARM64/RISC-V would love such a support.
Bye,
--
Oron Peled
On 2. 1. 2024 16:23, Vít Ondruch wrote:
>
>
> Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a):
>>
>>
>> On Tue, 2 Jan 2024 at 06:21, Vít Ondruch <vondruch(a)redhat.com> wrote:
>>
>>
>> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
>>> The dynamic linker already has the `glibc-hwcaps` mechanism to load
>>> optimized implementations of ''shared objects'' [3].
This means that
>>> packages can provide optimized libraries and they linker will be
>>> automatically load them from separate directories if appropriate.
>>> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
>>>
>>
>> Is this something specific to x86_64 that the libs needs to be
>> nested in a place such as
>> `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g.
>> `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more
>> universal.
>>
>>
>> Adding directories to the /usr sub-space generally gets bogged down
>> into 'You are polluting my name-space' arguments which get no-where
>> because some of the people getting angry is having to live with some
>> 3rd party rules and regulations which stipulated how things look and
>> will only get updated once a decade or so. [The same goes with
>> subdirectories in /usr/bin etc where it causes similar problems.]
>> There tends to be no 'general' case which works unless it gets
>> 'agreed' upon by some outside of the distro body that publishes
>> 'versioned' standards.
>
>
> Checking what Debian does, they have paths such as
> `/usr/lib/x86_64-linux-gnu/`. So we would not be alone.
>
>
> Vít
>
>
>> Vít
>>
>> --
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines:
>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>>
>>
>>
>> --
>> _______________________________________________
>> devel mailing list --devel(a)lists.fedoraproject.org
>> To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
>> Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedora...
>> Do not reply to spam, report
it:https://pagure.io/fedora-infrastructure/new_issue
>
> --
> _______________________________________________
> devel mailing list --devel(a)lists.fedoraproject.org
> To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
> Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedora...
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
--
Oron Peled Voice: +972-4-8228492
Unsolicited commercial email read for $500 per message.
--------
[1] https://wiki.debian.org/Multiarch
6:50 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
Oron Peled writes:
• I.e: a developer that need cross-compilation, install the wanted
toolchain(s) and all library packages are immediately available from standard
repositories.
I guess Fedora people that work on ARM/ARM64/RISC-V would love such a
support.
There are a number deb packaging policies that rpm would be wise to adopt.
A package's shared libraries get rolled into a separate <library><soname>
package right off the bat. An ABI break and a transition where both the new
and the old libraries must coexist becomes a nothing-burger. The updated
package's libraries go into a subpackage with, effectively, a new name that
does not cause the older library's uninstallation. There is no need to
create a compat package. It's the same package, from the previous version.
7:12 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On Thu, Jan 4, 2024 at 7:50 AM Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
Oron Peled writes:
> • I.e: a developer that need cross-compilation, install the wanted
> toolchain(s) and all library packages are immediately available from standard
> repositories.
>
> I guess Fedora people that work on ARM/ARM64/RISC-V would love such a
> support.
There are a number deb packaging policies that rpm would be wise to adopt.
A package's shared libraries get rolled into a separate
<library><soname>
package right off the bat. An ABI break and a transition where both the new
and the old libraries must coexist becomes a nothing-burger. The updated
package's libraries go into a subpackage with, effectively, a new name that
does not cause the older library's uninstallation. There is no need to
create a compat package. It's the same package, from the previous version.
That is not a deb vs rpm thing, plenty of rpm distributions do it. We
don't do it in Fedora because we don't want it to be automatic for
older libraries to hang around, plain and simple.
--
真実はいつも一つ！/ Always, there's only one truth!
7:06 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
On Tue, Jan 2, 2024 at 1:20 PM Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
The dynamic linker already has the `glibc-hwcaps` mechanism to load
optimized implementations of ''shared objects'' [3]. This means that
packages can provide optimized libraries and they linker will be
automatically load them from separate directories if appropriate.
(For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
Is this something specific to x86_64 that the libs needs to be nested in a place such as
`/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g. `/usr/x86-64-v{2,3,4}/lib`
directories instead? Or something more universal.
IIRC this is not specific to x86_64 (other arches can also use it).
This is specific to glibc implementation (implemented 4 years ago
IIRC). The paths glibc dynamic loader looks for shared libraries does
not change, but it will check specific subdirectories based on your
hardware capabilities.
I believe openSUSE already ships optional architecture optimized
packages, which use exactly this glibc feature.
david
>
> Vít
>
> --
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
8 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
* Vít Ondruch:
Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
The dynamic linker already has the `glibc-hwcaps` mechanism to load
optimized implementations of ''shared objects'' [3]. This means that
packages can provide optimized libraries and they linker will be
automatically load them from separate directories if appropriate.
(For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
Is this something specific to x86_64 that the libs needs to be nested
in a place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not
use e.g. `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something
more universal.
The path layout was chosen so that ldconfig can auto-detect the
directories and process their contents, without having to know which
subdirectories are recognized by the dynamic loader (and in fact,
arbitrary directories can be added using ld.so --glibc-hwcaps-prepend).
Thanks,
Florian
9:05 p.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
Hi,
On 12/28/23 10:12, Aoife Moloney wrote:
Wiki ->
https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_A...
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Additional paths will be inserted into the search path used for
executables on systems which have a compatible CPU.
Those additional paths will mirror the AMD64 "microarchitecture
levels" supported by the glibc-hwcaps mechanism: `x86-64-v2`,
`x86-64-v3`, `x86_64-v4`.
Systemd will be modified to insert the additional directories into the
`$PATH` environment variable (affecting all programs on the system)
and the equivalent internal mechanism in `systemd` (affecting what
executables are used by services).
Individual packages can provide optimized libraries via the
(trimming)
Glibc-hwcaps together with the new feature in systemd provide a
generic mechanism. It will be up to individual packages to actually
provide code which makes use of it. Individual package maintainers are
encouraged to benchmark their packages after recompilation, and
provide the optimized variants if useful. (I.e. the code in question
is measureably faster '''and''' the program is ran often enough
for
this to make a difference.)
The Change Owners will implement the packaging changes for a few
packages while developing the general mechanism and will submit those
as pull requests. Other maintainers are asked to do the same for their
packages.
Optimized variants of programs and libraries MAY be packaged in a
separate subpackage. The general packaging rules should be applied,
i.e. a separate package or packages SHOULD be created if it is files
are large enough.
Available benchmark results [2,4] are narrow and not very convincing.
We should plan an evaluation of results after one release. If it
turns out that the real gains are too small, we can scrap the effort.
On the other hand, we should also consider other architectures. For
example, microarchitecture levels `z{14,15}` for `s390x` or
`power{9,10}` for `ppc64le`. Other architectures are not included in
this Change Proposal to reduce its scope.
While I realize this is intended as an amd64 specific change, I'm
interested in helping to assure the infrastructure is in place for
similar testing of aarch64 packages, since we have similar problems.
There remains a desire to support arm v8.0 machines (ex: the rpi4) into
the foreseeable future, but significant uplifts exist for some
packages/workloads with newer arch revisions. In most cases those
features are currently being enabled at runtime but have perf hits for
operations that traditionally are just part of the instruction stream.
Outline-atomics, which leverage the v8.2 atomics are one such example,
but also SVE (vectors, used for crypto, regex, etc), and more recently
the v8.8 CPY (memcpy) should all ideally be inline.
So, while some other organizations have moved their platform/OSs to a
v8.2 baseline, it would be nice to have another fedora tool that can be
utilized to remain perf competitive.
== Feedback ==
== Benefit to Fedora ==
The developers who are interested in this kind of optimization work
can perform it within Fedora, without having to build separate
repositories. The users who have the appropriate hardware will gain
performance benefits. Faster code is also more energy-efficient. The
change will be automatic and transparent to users.
Note that other distributions use higher microarchitecture levels. For
example RHEL 9 uses x86-64-v2 as the baseline, RHEL 10 will use
x86-64-v3, and other distros provide optimized variants (OpenSUSE,
Arch Linux). We implement the same change in Fedora in a way that is
scoped more narrowly, but should provide the same performance and
energy benefits.
== Scope ==
* Proposal owners:
** Extend systemd to set the executable search path using the same
criteria as the dynamic linker.
** Implement packaging changes for at least one package with a library
and at least one package with executables and submit this as pull
requests.
** Provide a pull request for the Packaging Guidelines to describe the
changes listed in Description above.
* Other developers:
** Do benchmarking and implement packaging changes for other packages
if beneficial.
* Release engineering: [https://pagure.io/releng/issue/11864 #11864]
* Policies and guidelines: TBD.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No impact.
== How To Test ==
* Use `/usr/bin/ld.so --help` to check which hwcaps are supported by the system.
* Install one or more packages which provide optimized code.
* Restart the system or re-login to reinitialize `$PATH`.
* Check that appropriate directories are present in `$PATH`.
* Run some benchmarks and check that the optimized code is indeed faster.
== User Experience ==
There should be no impact for users. If the optimized code is
available and installed for their hardware, various tasks may finish
faster and use less energy.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Undo the changes in packages which introduced
them and recompile.
* Contingency deadline: Any time.
* Blocks release? No.
== Documentation ==
== Release Notes ==
Packages which benefit from being compiled for higher AMD64
microarchitecture levels (`x86-64-v2`, `x86-64-v3`, `x86_64-v4`) are
now provided with optimized variants which will be used automatically
on appropriate CPUs. This includes: TBD1, TBD2, TBD3.
5:42 a.m.
New subject: F40 Change Proposal: Optimized Binaries for the AMD64
Architecture (System-Wide)
We don't generally use/talk about amd64 in Fedora, so I was a bit thrown by
the naming of this Change.
I don't want to start a skirmish about amd64 vs x86_64, but iiuc this
Change is not AMD specific
so by now I personally feel x86-64 actually kinda sounds more neutral in
this sense
(I am aware that deb based distros favor "amd64" and some may consider it
more "PC").
Perhaps you could consider changing the naming in the title?
Further the text already talks a lot about x86-64-v{1,2,3,4}...
Jens
131
days inactive
156
days old
35 comments
24 participants
participants (24)
-
Aoife Moloney -
Barry Scott -
Chris Adams -
David Abdurachmanov -
Dominique Martinet -
Dridi Boukelmoune -
Fabio Valentini -
Florian Weimer -
Gary Buhrmaster -
Jens-Ulrik Petersen -
Jeremy Linton -
John Reiser -
Jonny Heggheim -
Marián Konček -
Mattia Verga -
Neal Becker -
Neal Gompa -
Oron Peled -
Panu Matilainen -
Robert Marcano -
Sam Varshavchik -
Stephen Smoogen -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek