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@lists.opensuse.org/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.
Zbyszek
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue