On Mon, Jan 13, 2025 at 09:18:46AM +0100, Vitaly Zaitsev via devel wrote:
> On 12/01/2025 20:36, Zbigniew Jędrzejewski-Szmek wrote:
> > I think any massive use of this scheme is unlikely. Note that we'd
> > want to this only for packages where the optimized code yields
> > noticeable benefits. There just aren't that many packages which do
> > significant number crunching_and_ don't already use some kind of
> > runtime cpu detection.
> 
> Most modern C/C++ applications that work with floating-point numbers can get
> a boost by using modern CPU instructions. This speedup can be small or
> significant, depending on the number of calculations.
> 
> I think such optimized binaries should go into a separate RPM packages and
> should be handled by dnf depending on the running architecture. This would
> solve both the disk space and latency issues.

First, this would require setting up the infrastructure to build and
store and distribute multiple builds of a single version of a
package. This is something that Fedora currently doesn't do, so it'd
require changes to operations in mock, koji, bodhi, the CI, mirrors.

Second, dnf would need to learn about this and install the appropriate
variant.

Third, this choice would be "permanent", i.e. it would be done once at
package installation time. If the user tries to boot the same image
on different hardware, it might fail. This is inferior to the proposed
approach where the choice is made at runtime.

Fourth, this would actualy use more space. Most packages have only a
little bit of code and a lot of other files, so duplicating whole
packages to provide different variants of a few binaries would not
be space efficient.

> Example: firefox-134.0-1.fc42.x86_64 vs firefox-134.0-1.fc42.x86_64-v2.
> 
> Since the number of these optimized packages will be small, I think it's
> worth the CPU time to build them twice.
> 
> > Benchmarks indicate 100–1000 μs.
> 
> 1 second? I think it's too much.

As mentioned in David's reply, you got the orders of magnitude very
wrong. There is no latency issue.

Zbyszek
-- 
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Reply via email to