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@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
