On Tue, Apr 04, 2023 at 11:17:50AM +0200, Jakub Jelinek wrote: > On Tue, Apr 04, 2023 at 07:37:59AM +0000, Zbigniew Jędrzejewski-Szmek 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%. > > Given that GCC 12 and later autovectorizes at -O2, it might be more than > 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. > > Why a subrpm? Should be possible to just arrange for one src.rpm to > build the library twice and install the x86-64-v3 into > /usr/lib64/glibc-hwcaps/x86-64-v3/ > Perhaps come with some macro to simplify that for packagers. If we start compiling libaries twice, it'd double the package sizes (or actually more than double, since in the benchmarks the code size with -v3 is also increased slightly). I assume people would want to get the optimized form split out to a subpackage so people who don't use this, don't pay the price. If we use the new "dynamic subpackages" feature of RPM, and some smart macros, this could even not be a big packaging burden. 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
