On June 17, 2021 12:08:44 AM UTC, Neal Gompa <ngompa13@xxxxxxxxx> wrote: >On Wed, Jun 16, 2021 at 6:08 PM Kevin Kofler via devel ><devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: >> >> Neal Gompa wrote: >> > Yeah, I think that proposal was not workable because of AVX2. The >> > x86_64-v2 subarch adds SSSE3, SSE4.2, POPCNT, and CMPXCHG16B to the >> > current x86_64 baseline. All of these instructions were present in >the >> > first Intel Macs launched in 2007, as I recall. >> >> Still means my Core 2 Duo notebook would no longer be able to run >Fedora. >> >> >> Different question: How is the runtime CPU feature detection / >> >> dispatch support in glibc coming along? Shouldn't this "work" by >now? >> > >> > No idea, good question, though! >> >> Indeed, runtime detection is clearly the way to go. >> >> Why does this proposal to desupport hardware for no good reason >(because the >> performance gain can be obtained in a compatible way, where it is >even >> noticeable at all) keep coming up again and again? >> > >It keeps coming up because we don't have support for subarches in RPM >for anything but ARM architectures. That deficiency forces us to keep >considering raising the baseline instead of being able to have select >packages with subarch content. This is important because not >everything *can* use glibc-hwcap hardware detection at runtime, and >sometimes you need optimized binaries. Honestly, this sounds to me like we rather should find a solution how to "fix" this in RPM (I know of the previous unsuccessful attempts). Otherwise I don't really see compelling reasons why we should raise the baseline to x86_64v2 when it provides very small gain. Because in contrast to runtime detection or cutting edge software, this has the disadvantage that once you raise it, you throw people out. So it better be worth it and ATM I don't see why it is. > > >-- >真実はいつも一つ！/ Always, there's only one truth! >_______________________________________________ >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 on the list, report it: >https://pagure.io/fedora-infrastructure _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
