On Fri, Jan 10, 2025 at 07:28:19PM +0000, Aoife Moloney via devel-announce wrote:
> == Summary ==
> Individual packages can provide already optimized libraries via the
> glibc-hwcaps mechanism. This approach will be extended to executables.
> The package provides an optimized variant of a binary in a different
> directory. A symlink to small program which replaces the binary in
> `/usr/bin`. At runtime, this program will find the most appropriate
> variant and execute it.
Can this provide an example of the binary naming convention that
is anticipated. I'm guessing it'll be something like
/usr/bin/fish ---> glibc-hwcaps-helper (symlink)
and then it'll invoke one of
/usr/bin/fish-x86-64
/usr/bin/fish-x86-64-v2
/usr/bin/fish-x86-64-v3
/usr/bin/fish-x86-64-v4
depending on what exists.
Will we mandate that the x86-64 baseline binary *always* exists,
or will we allow for the possibility of shipping binaries that
*only* build for say x86_64-v2, with *no* x86_64 support ?
> ''Which'' packages provide the optimized code and at which level will
> be made by individual package maintainers based on benchmark results.
> A few programs/packages will be updated by the Change Owners to show
> how the mechanism works.
I'm assuming the change owners already have the set of packages/programs
in mind that justify doing this work. Please provide this list of
proposed adoptees, and the anticipated performance benefits for them.
> 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}/`.)
If we have binaries for non-default ABI levels, will each binary
be linking to the corresponding /usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}
library directly, or will all binaries link to the /usr/lib64/libfish.so
and then still rely on glibc-hwcaps resolving the best.
> 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.
Can we again say whether the x86-64 binary is *mandatory* for the
base RPM, or x86_64-vNNN is permitted as a only binary provided.
> 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.
I would expect this change to have a list of a handful of binaries
that are proposed to adopt this scheme initially, along with their
expected performance benefits. Implementing something and then
wondering if it benefits performance later feels like the wrong
way around.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
