Hi Dominique, Am Do., 8. Dez. 2022 um 17:36 Uhr schrieb Dominique Leuenberger / DimStar <dimstar@opensuse.org>:
## openSUSE Tumbleweed x86_64 stays at baseline ##
Thank you for the courage to change course, and I support this. This makes most sense for now. We should be updating the news.o.org post about this.
https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels. It's even very likely that we come up with a plan of using combinations (of e.g hwcaps plus a 2nd baseline repo)
I have made a ~ working prototype of this idea using the glibc-hwcaps feature, which currently requires zero modification to the spec files. if you want to take a look, it is at https://build.opensuse.org/project/show/home:dirkmueller:branches:openSUSE:F... but there are a couple of messy things in there that need to be cleaned up but it shows how things could be working. Michael Schroeder is currently working on being able to build x86_64 and x86_64_vX (v3 most likely) without having to resort to multiple repositories, which has a buildcounter sync issue. This should be fixed later today I hope. what we're currently doing: * we're building selected libraries (as a prototype example libpython3.10, zstd and zlib) for x86_64-v3 and -v2 (as well as x86_64) * they're being repackaged via a slightly improved baselibs.conf mechanics automatically into for example libpython310-x86_64-v3.x86_64.rpm. This package looks like this: $ rpm -ql libpython3_10-1_0-x86-64-v3 /usr/lib64/glibc-hwcaps /usr/lib64/glibc-hwcaps/x86-64-v3 /usr/lib64/glibc-hwcaps/x86-64-v3/libpython3.10.so.1.0 python3.10 is using that on my host (which is -v3 capable). it wouldn't be used on older hardware $ ldd /usr/bin/python3 linux-vdso.so.1 (0x00007fff16d09000) libpython3.10.so.1.0 => /lib64/glibc-hwcaps/x86-64-v3/libpython3.10.so.1.0 (0x00007f71ae400000) libc.so.6 => /lib64/libc.so.6 (0x00007f71ae205000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f71ae7f2000) libm.so.6 => /lib64/libm.so.6 (0x00007f71ae121000) /lib64/ld-linux-x86-64.so.2 (0x00007f71ae84f000) the drop in is built for x86_64_v3: $ readelf -a /usr/lib64/glibc-hwcaps/x86-64-v3/libpython3.10.so.1.0 | grep x86-64-v3 x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3 Also in this case, the library size is the same size. I have seen cases where it got marginally smaller and marginally larger also. the package is requiring the x86_64 base library package (that installs into /usr/lib64) and supplements it, so it will be installed when available and upgraded alongside the main version (or deinstalled, for that matter): $ rpm -q --requires libpython3_10-1_0-x86-64-v3 libpython3_10-1_0 = 3.10.8-5.1 [...] $ rpm -q --supplements libpython3_10-1_0-x86-64-v3 libpython3_10-1_0 = 3.10.8 there is a "supplements: <name> and <host wants v3>" missing, but I don't have that part figured out yet. It can be done later. and I'm happy to import that it has measurable performance gain in the pybenchmark for pydigits: x86_64-v3: ### pidigits ### Mean +- std dev: 174 ms +- 1 ms vs x86_64-baseline: ### pidigits ### Mean +- std dev: 181 ms +- 1 ms This is btw the only benchmark I found that shows improvements. There are others (like rpm2cpio on xonotic-data) that show mild performance *decrease* by switching to x86_64-v3. which further emphasizes the point that we should not globally raise the bar but only do so for known cases where things are known to be improving. So you get a ~ 4% performance increase on this single benchmark by accepting to install another 3mb of shared library. it would only be installed if the hardware supports it, and even if it is installed it would only be used when the hardware is capable of running the optimized version. so providing the speedup, but no incompatibility for any user. Greetings, Dirk