On Tue, Apr 04, 2023 at 09:05:43AM -0400, Stephen Smoogen wrote: > On Tue, 4 Apr 2023 at 08:52, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> > wrote: > > > 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. > > > > > My guess is that the burden would be shifted to the builders and the > background storage. Won't package builds need to be done 'twice' for > various parts to get two different sets of libraries? Memory and CPU usage > of the builders will be impacted and so would storage size. > > Those aren't 'free' as > a) X build taking N% longer means Y has to wait that much longer for their > build to complete. > b) koji storage of builds is finite and Fedora is hitting the limits > regularly. This means build storage times will have to be shortened again > so that builds can complete. Cleaning it out and moving things around take > a significant amount of compute time on koji further slowing down things. > c) there are a limited number of physical machines in Fedora and no room to > add more. > d) The resources needed for each build grows and so the virtual builders > need to be segmented into fewer systems. > e) Mirrors are impacted by the larger packages as it takes longer for them > to sync out changes in Fedora. > > This doesn't mean this is a bad or impossible issue to deal with, but it > needs to be clear what the costs are so when changes are needed to deal > with those and other impacts, it doesn't come as a surprise to the packager > community. Yes, exactly. The cost is clear, the benefit less so. My thinking was to figure out the packages where there's actually a measureable tangible benefit, and only do this there. For example, vorbis, flac, zstd benefit 5–20% in [1]. [1] https://sunnyflunk.github.io/2023/01/15/x86-64-v3-Mixed-Bag-of-Performance.html _______________________________________________ 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
