On Sun, Apr 2, 2023 at 5:37 PM Mattia Verga via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Il 31/03/23 17:27, Florian Festi ha scritto: > > On 3/31/23 15:40, Stephen Gallagher wrote: > >> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > >>> https://fedoraproject.org/wiki/Changes/RPM-4.19 > >>> == Detailed Description == > >>> RPM 4.19 contains various improvements over previous versions. Many of > >>> them are internal in nature such as moving from automake to cmake, > >>> improvements to the test suite, stripping copies of system functions, > >>> splitting translations into a separate project and more. There are > >>> still several user facing changes: > >>> > >>> * New rpmsort(8) utility for sorting RPM versions > >> Handy! > >> > >>> * x86-64 architecture levels (v2-v4) as architectures > >> Could you explain more what this means, exactly? > > No! But here is the commit: > > > > https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847 > > > > It looks like it adds x86_64_v2, x86_64_v3 and x86_64_v4. Something > > about some x86_64 processors having additional capabilities. > > > Is there anyone who could provide some benchmarks to see if there are > significant performance improvements about using v2/v3/v3 versus plain > x86_64? If so, do you think we could drop building i686 by default (to > save some resources) and provide v2 (or v3, or v4) alongside x86_64? I don't think we can drop i686 as long as we need to support at least a subset of i686 for wine / steam / $your favourite 32-bit only third-party application. Additionally, I don't think building x86_64-v2 / x86_64-v3 / x86_64-v4 variants of *all* packages that are built on x86_64 makes sense. Some packages already have runtime detection of available CPU features and will choose the fastest path without having to be compiled for it explicitly. Other libraries will not really benefit from newer x86_64 instructions. But there are some libraries that *would* benefit quite a bit, and we could look into whether it's possible to optionally build additional versions of these select packages. As far as I know, this is also the approach that OpenSUSE has chosen. Fabio _______________________________________________ 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
