Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, 4 Apr 2023 at 05:18, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Tue, Apr 4, 2023 at 3:38 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> On Sun, Apr 02, 2023 at 09:54:04PM +0200, Dan Čermák wrote:
> > The only benchmark that *I* am aware of is this one done by Martin
> > Jambor: https://jamborm.github.io/spec-2022-07-29-levels/
>
> This is very … underwhelming. x86-64-v2 is essentially identical to x86-64-v1.
> x86-64-v3 is better. It even shows speed-ups of 20%, but only with -Ofast.
> And -Ofast is not something that can be enabled as a default build flag,
> because it leads to surprising and unpredictable behaviour in some cases. (*)
> At -O2, which we use, the speed up is maybe 10%.
>
> > tl;dr; v2 does not really bring notable improvements, only v3 but also
> > only in some selected synthetic benchmarks.
> >
> > openSUSE Tumbleweed went a different route and chose to utilize
> > glibc-hwcaps instead:
> > https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels
> > https://lists.opensuse.org/archives/list/factory@xxxxxxxxxxxxxxxxxx/thread/ZOHLT4CQ7TDOJJ2VV7HKMN5G2MR2CTMD
>
> Yeah, I think that's the way to go. I think we should identify 100
> shared libraries which would be positively impacted by x86-64-v3
> and provide a -v3 subrpm for them. This would be a nice feature for
> F40.
>

This is further confirmed by Arch's data that even x86_64-v3 isn't
necessarily great either:
https://sunnyflunk.github.io/2023/01/15/x86-64-v3-Mixed-Bag-of-Performance.html

It seems that moving to -O3 would provide more gains than x86_64-v3.

Otherwise, the only thing you really get from moving subarches is
breaking lots of hardware.


I think that we are seeing the 'long tail' of small/tiny performance increases on x86_64 due to multiple factors about the underlying architecture and the end of Moore's law. Basically a lot of things will be touted as big things and may be some improvement for specific workloads, but the majority of work will see nothing 'large' enough that people feel value for it after they paid for it. 
 


--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux