Decision on Tumbleweed x86_64 Architecture level
Dear Tumbleweed users and hackers, First, thank you all for the (mostly) constructive discussion around this topic. The thread got pretty long and I think no more new arguments have been surfacing lately. Let me give a quick overview of what will happen from here on: ## openSUSE Tumbleweed x86_64 stays at baseline ## + We will push on finding a better solution than moving the entire distro to any other architecture level. We're currently collecting ideas/proposals/solutions at 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) ## openSUSE Tumbleweed i586 downgraded to a port ## The i586 architecture keeps moving to openSUSE:Factory:LegacyX86 (the name still matches luckily). The repository will be published at https://download.opensuse.org/ports/i586/tumbleweed/repo/oss/. The usercount there is non-zero, but certainly not as large as the x86_64 userbase. For this port, it would still be great if there was a volunteer looking after it. It would mostly consist of verifying the QA runs, most often cross-checking failures against the x86_64 port, filing new bugs if not identical on x86_64 (or not already filed by other ports) and keep an eye on the build state of the repository. This is a task that does not require coding skills (it can help, but is not mandatory). I stronlgy believe that this is the best approach we can take to serve our contributors and users. Best regards, Dominique
Dominique Leuenberger / DimStar composed on 2022-12-08 17:35 (UTC+0100):
## openSUSE Tumbleweed x86_64 stays at baseline ##
Happy!!!
## openSUSE Tumbleweed i586 downgraded to a port ## The i586 architecture keeps moving to openSUSE:Factory:LegacyX86 (the name still matches luckily). The repository will be published at https://download.opensuse.org/ports/i586/tumbleweed/repo/oss/. The usercount there is non-zero, but certainly not as large as the x86_64 userbase. For this port, it would still be great if there was a volunteer looking after it. It would mostly consist of verifying the QA runs, most often cross-checking failures against the x86_64 port, filing new bugs if not identical on x86_64 (or not already filed by other ports) and keep an eye on the build state of the repository. This is a task that does not require coding skills (it can help, but is not mandatory).
"Coding skills" I have are limited to nominal shell basics. The little I knew about building I've long since forgotten about. English words I can deal with, but not other langs or most icons. Is there a wiki page describing these looking afters in a little more detail? Bugs I learned how to file before I learned about SuSE. Of P4-32s I have 8 with TW dup'd within the past 7 months, plus a P4-64 with 32bit TW20221128. I even have P3s with TW20220505 & TW20220725. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Thu, 2022-12-08 at 18:15 -0500, Felix Miata wrote:
"Coding skills" I have are limited to nominal shell basics. The little I knew about building I've long since forgotten about. English words I can deal with, but not other langs or most icons. Is there a wiki page describing these looking afters in a little more detail? Bugs I learned how to file before I learned about SuSE. Of P4-32s I have 8 with TW dup'd within the past 7 months, plus a P4-64 with 32bit TW20221128. I even have P3s with TW20220505 & TW20220725.
No, so far we don't have a wiki page. But if you're willing to take on the task to look after the port, I'm sure we'll get you started. Cheers, Dominique
On Fri, Dec 09, 2022 at 08:03:48AM +0100, Dominique Leuenberger / DimStar wrote:
On Thu, 2022-12-08 at 18:15 -0500, Felix Miata wrote:
"Coding skills" I have are limited to nominal shell basics. The little I knew about building I've long since forgotten about. English words I can deal with, but not other langs or most icons. Is there a wiki page describing these looking afters in a little more detail? Bugs I learned how to file before I learned about SuSE. Of P4-32s I have 8 with TW dup'd within the past 7 months, plus a P4-64 with 32bit TW20221128. I even have P3s with TW20220505 & TW20220725.
No, so far we don't have a wiki page. But if you're willing to take on the task to look after the port, I'm sure we'll get you started.
It's exactly this attitude that makes a lot of things in openSUSE mysterious and unapproachable. Maybe you could get the wiki page started instead? Thanks Michal
On Thu, Dec 08, 2022 at 05:35:59PM +0100, Dominique Leuenberger / DimStar wrote:
Dear Tumbleweed users and hackers,
First, thank you all for the (mostly) constructive discussion around this topic. The thread got pretty long and I think no more new arguments have been surfacing lately.
Let me give a quick overview of what will happen from here on:
## openSUSE Tumbleweed x86_64 stays at baseline ## + We will push on finding a better solution than moving the entire distro to any other architecture level. We're currently collecting ideas/proposals/solutions at 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)
## openSUSE Tumbleweed i586 downgraded to a port ## The i586 architecture keeps moving to openSUSE:Factory:LegacyX86 (the name still matches luckily). The repository will be published at https://download.opensuse.org/ports/i586/tumbleweed/repo/oss/. The usercount there is non-zero, but certainly not as large as the x86_64 userbase. For this port, it would still be great if there was a volunteer looking after it. It would mostly consist of verifying the QA runs, most often cross-checking failures against the x86_64 port, filing new bugs if not identical on x86_64 (or not already filed by other ports) and keep an eye on the build state of the repository. This is a task that does not require coding skills (it can help, but is not mandatory).
Will the 32bit libs stay for e.g. use by Wine? Ciao, Marcus
On Fri, 2022-12-09 at 09:12 +0100, Marcus Meissner wrote:
## openSUSE Tumbleweed i586 downgraded to a port ## The i586 architecture keeps moving to openSUSE:Factory:LegacyX86 (the name still matches luckily). The repository will be published at https://download.opensuse.org/ports/i586/tumbleweed/repo/oss/. The usercount there is non-zero, but certainly not as large as the x86_64 userbase. For this port, it would still be great if there was a volunteer looking after it. It would mostly consist of verifying the QA runs, most often cross-checking failures against the x86_64 port, filing new bugs if not identical on x86_64 (or not already filed by other ports) and keep an eye on the build state of the repository. This is a task that does not require coding skills (it can help, but is not mandatory).
Will the 32bit libs stay for e.g. use by Wine?
Yes; we don't want to lose wine support. Out of the 15k packages, about 800 are currently building -32bit packages, so are the ones we plan on keeping. Cheres, Dominique
Hello to all, I don't if this kist is the right one if I to run meld, i.e, meld (from the command line, i receive the following) Traceback (most recent call last): File "/usr/bin/meld", line 96, in <module> import meld.conf # noqa: E402 ModuleNotFoundError: No module named 'meld' then running (downloaded from meldmerge.org/) meld-3.22.0/bin/meld I got two windows one with "meld" in the titlebar and nothing else and a second one with "meld" also in the titlebar and additionally saying "Meld requires Gtk+3.20 or higher" I am running tumbleweed with openSUSE | Produkt | 20221206-0 and all dependicies for meld, including Gtk+3.22. I don't have any clues where to look for and appreciate any help. Regards Hartmut Rosch Delmenhorst -----------
Hi Hartmut, On Fri, 2022-12-09 at 12:00 +0100, Hartmut Rosch wrote:
Hello to all,
I don't if this kist is the right one
This list is about development of Tumbleweed and the directions it takes. Your query rather belongs to the support list (I cross-posted this reply to support; please only reply to the support list, not factory for this topic)
if I to run meld, i.e,
Is this the meld version from Tumbleweed? ("rpm -qi meld" please)
meld (from the command line, i receive the following) Traceback (most recent call last): File "/usr/bin/meld", line 96, in <module> import meld.conf # noqa: E402 ModuleNotFoundError: No module named 'meld'
That sounds very strange, and somewhat implies that the meld verison you have installed is either defective or not compatible with the default python interpreter on your system. Please check the outputs of: rpm -qV meld if that gives no putput, check "rpm -ql meld" and take note of the lines containing python.*/site-packages. Then verify "python3 --version"; does the version number found in the output earlier match the one from python3 --version (only the first two are relevant, so in case it gives 3.10.8, only 3.10 is relevant)
then running (downloaded from meldmerge.org/)
meld-3.22.0/bin/meld
I got two windows one with "meld" in the titlebar and nothing else and a second one with "meld" also in the titlebar and additionally saying "Meld requires Gtk+3.20 or higher"
That's something for upstream to answer. Tumbleweed ships meld as a package which is integrated into the sytsem. Cheers, Dominique
i586 downgraded to a port So it means that the remaining 32bit packages in main Tumbleweed will be rebuilt with -march=x86-64, right? What is going to be the RPM architecture name for them?
Theoretically it should be `pentium4` but it is currently broken in RPM upstream: https://github.com/rpm-software-management/rpm/issues/2147 [Fedora currently uses `i686` for this, which is confusing.]
On Fri, 2022-12-09 at 11:21 +0000, Bruno Pitrus wrote:
i586 downgraded to a port So it means that the remaining 32bit packages in main Tumbleweed will be rebuilt with -march=x86-64, right? What is going to be the RPM architecture name for them?
That's one of the next steps to look at after the i586 port is properly split out, yes.
Theoretically it should be `pentium4` but it is currently broken in RPM upstream: https://github.com/rpm-software-management/rpm/issues/2147
They are going to stay as they are now: the rpm shipping the -32bit libraries have always been packaged as x86_64, as this is the target arch the package is meant for. Sample from zypper: | xcb-util-image-devel-32bit | package | 0.4.1-1.1 | x86_64 | openSUSE-Tumbleweed-Oss Cheers, Dominique
On Fri, 9 Dec 2022, Dominique Leuenberger / DimStar wrote:
On Fri, 2022-12-09 at 11:21 +0000, Bruno Pitrus wrote:
i586 downgraded to a port So it means that the remaining 32bit packages in main Tumbleweed will be rebuilt with -march=x86-64, right? What is going to be the RPM architecture name for them?
That's one of the next steps to look at after the i586 port is properly split out, yes.
Note this is already done for SLES 15+ (which has no 32bit support): %if "%{TARGET_ARCH}" == "i586" %if 0%{?sle_version:%sle_version} >= 150000 --with-arch-32=x86-64 \ %else --with-arch-32=i586 \ %endif --with-tune=generic \ %endif %if "%{TARGET_ARCH}" == "x86_64" %ifnarch %{disable_multilib_arch} --enable-multilib \ --with-arch-32=x86-64 \ %endif --with-tune=generic \ %endif since most -32bit libraries are built from within a 32bit tree (and with 32bit gcc) both of the above are necessary. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
On Sun, 2022-12-11 at 10:09 +0000, Richard Biener wrote:
On Fri, 9 Dec 2022, Dominique Leuenberger / DimStar wrote:
On Fri, 2022-12-09 at 11:21 +0000, Bruno Pitrus wrote:
i586 downgraded to a port So it means that the remaining 32bit packages in main Tumbleweed will be rebuilt with -march=x86-64, right? What is going to be the RPM architecture name for them?
That's one of the next steps to look at after the i586 port is properly split out, yes.
Note this is already done for SLES 15+ (which has no 32bit support):
%if "%{TARGET_ARCH}" == "i586" %if 0%{?sle_version:%sle_version} >= 150000 --with-arch-32=x86-64 \ %else --with-arch-32=i586 \ %endif --with-tune=generic \ %endif %if "%{TARGET_ARCH}" == "x86_64" %ifnarch %{disable_multilib_arch} --enable-multilib \ --with-arch-32=x86-64 \ %endif --with-tune=generic \ %endif
That's done as part of the gcc spec file? Or where does this happen? Beware that we will still have a full i586 port (openSUSE:Factory:LegacyX86) which inherits all sources directly from openSUSE:Factory. So we have to find a way to enable this in the future* for openSUSE:Factory, but not for openSUSE:Factory:LegacyX86 Cheers, Dominique * future should be after March 2023; that's the scheduled date to drop the full i586 repository from Tumbleweed and only have i586 in the ports.
On Mon, 12 Dec 2022, Dominique Leuenberger / DimStar wrote:
On Sun, 2022-12-11 at 10:09 +0000, Richard Biener wrote:
On Fri, 9 Dec 2022, Dominique Leuenberger / DimStar wrote:
On Fri, 2022-12-09 at 11:21 +0000, Bruno Pitrus wrote:
i586 downgraded to a port So it means that the remaining 32bit packages in main Tumbleweed will be rebuilt with -march=x86-64, right? What is going to be the RPM architecture name for them?
That's one of the next steps to look at after the i586 port is properly split out, yes.
Note this is already done for SLES 15+ (which has no 32bit support):
%if "%{TARGET_ARCH}" == "i586" %if 0%{?sle_version:%sle_version} >= 150000 --with-arch-32=x86-64 \ %else --with-arch-32=i586 \ %endif --with-tune=generic \ %endif %if "%{TARGET_ARCH}" == "x86_64" %ifnarch %{disable_multilib_arch} --enable-multilib \ --with-arch-32=x86-64 \ %endif --with-tune=generic \ %endif
That's done as part of the gcc spec file? Or where does this happen? Beware that we will still have a full i586 port (openSUSE:Factory:LegacyX86) which inherits all sources directly from openSUSE:Factory. So we have to find a way to enable this in the future* for openSUSE:Factory, but not for openSUSE:Factory:LegacyX86
Yes, that's happening in the GCC spec file which is where we historically set the base architecture levels (because %optflags doesn't neccessarily reach all gcc invocations). Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
On 12/9/22 12:21, Bruno Pitrus wrote:
i586 downgraded to a port
So it means that the remaining 32bit packages in main Tumbleweed will be rebuilt with -march=x86-64, right? What is going to be the RPM architecture name for them?
If you rebuild them with "-march=x86_64", they become 64-bit binaries. Packages with the -32bit suffix are 32-bit binaries repacked into x86_64 RPM packages, if you change -march to x86_64, they become 64-bit binaries packed into x86_64 RPM packages. Adrian
No. -m32 vs -m64 steers whether it is a 32 vs 64bit binary -march=… only changes what instructions GCC is allowed to use. If we do not build an actual 32-bit distro, we should allow GCC to use those instructions which are available on all 64-bit CPUs, also in 32-bit code. (Especially SSE2 which is a massive improvement)
On 12/9/22 12:50, Bruno Pitrus wrote:
No. -m32 vs -m64 steers whether it is a 32 vs 64bit binary
-march=… only changes what instructions GCC is allowed to use.
If we do not build an actual 32-bit distro, we should allow GCC to use those instructions which are available on all 64-bit CPUs, also in 32-bit code. (Especially SSE2 which is a massive improvement)
When you pass -m32 -march=x86-64, you are still getting the i386 baseline: glaubitz@nofan:~> echo -e '#include <stdio.h> \n int main() { printf("Hello World!"); return 0; }' | x86_64-linux-gnu-gcc -m32 -march=x86-64 -x c - -o hello-world && file hello-world hello-world: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=38274ac9ecf2295ea98525aac114a5672c5f6593, for GNU/Linux 3.2.0, not stripped What you mean is x32 which is a separate ABI and AFAIK not supported in openSUSE but in Debian only: glaubitz@nofan:~> echo -e '#include <stdio.h> \n int main() { printf("Hello World!"); return 0; }' | x86_64-linux-gnu-gcc -mx32 -march=x86-64 -x c - -o hello-world && file hello-world hello-world: ELF 32-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /libx32/ld-linux-x32.so.2, BuildID[sha1]=e716dabf9377c5c5d0062bbdd2d4b39cfa7eda2f, for GNU/Linux 3.4.0, not stripped glaubitz@nofan:~> Adrian
You're confusing things. I know what x32 is and nobody cares about supporting it. (There was an aborted effort at porting Tumbleweed to the ARM equivalent of x32, fwiw) `file` is not going to tell you what instructions an executable contains, it only looks at the elf header. Try to compile an executable which runs a more complicated algorithm (copying an array of a dozen elements should suffice) with -march=i586 and x86-64. if you examine them in objdump, the second should contain SSE instructions.
On 12/9/22 15:44, Bruno Pitrus wrote:
You're confusing things. I know what x32 is and nobody cares about supporting it. (There was an aborted effort at porting Tumbleweed to the ARM equivalent of x32, fwiw)
Sure, it's still supported in Debian and Gentoo :-).
`file` is not going to tell you what instructions an executable contains, it only looks at the elf header. Try to compile an executable which runs a more complicated algorithm (copying an array of a dozen elements should suffice) with -march=i586 and x86-64. if you examine them in objdump, the second should contain SSE instructions.
I understand what you mean now. But I'm not sure whether the x86-64 baseline with the limited set of registers on i386 will bring you any remarkable benefit. After all, x32 was created to be able to really profit from x86-64 features on a 32-bit target. I don't really like the repacking approach of 32-bit binaries into 64-bit RPMs. MultiArch would have been the cleaner way with the 32-bit packages using the i686 baseline. Adrian
On Fri, Dec 09, 2022 at 04:46:20PM +0100, John Paul Adrian Glaubitz wrote:
On 12/9/22 15:44, Bruno Pitrus wrote:
You're confusing things. I know what x32 is and nobody cares about supporting it. (There was an aborted effort at porting Tumbleweed to the ARM equivalent of x32, fwiw)
Sure, it's still supported in Debian and Gentoo :-).
`file` is not going to tell you what instructions an executable contains, it only looks at the elf header. Try to compile an executable which runs a more complicated algorithm (copying an array of a dozen elements should suffice) with -march=i586 and x86-64. if you examine them in objdump, the second should contain SSE instructions.
I understand what you mean now. But I'm not sure whether the x86-64 baseline with the limited set of registers on i386 will bring you any remarkable benefit.
Hard to tell without measurements. Still SSE does give you extra registers so it should help especially for 32bit where the base registers are limited. Nonetheless, we *do* intend to still provide a 32bit port, and unless the 32bit libraries are to be built twice they should be built for the 32bit architecture we provide as the LegacyX86 port.
After all, x32 was created to be able to really profit from x86-64 features on a 32-bit target.
But the 32bit libraries are in part for support of legacy binaries and changing the ABI is not going to work for that. Thanks Michal
On 12/9/22 17:26, Michal Suchánek wrote:
I understand what you mean now. But I'm not sure whether the x86-64 baseline with the limited set of registers on i386 will bring you any remarkable benefit.
Hard to tell without measurements. Still SSE does give you extra registers so it should help especially for 32bit where the base registers are limited.
Sure, some benefit will be there. But I doubt it's really measurable.
Nonetheless, we *do* intend to still provide a 32bit port, and unless the 32bit libraries are to be built twice they should be built for the 32bit architecture we provide as the LegacyX86 port.
Well, if you repackage 32-bit binaries into x86_64, you're not going to install them on a pure 32-bit system are you?
After all, x32 was created to be able to really profit from x86-64 features on a 32-bit target.
But the 32bit libraries are in part for support of legacy binaries and changing the ABI is not going to work for that.
I wasn't seriously suggesting that. I was just confused by Bruno's suggestion as I have never seen the approach of using -march=x86-64 together with -m32. As I said, I'm more a fan of the MultiArch approach as it avoids the whole effort of repackaging 32-bit binaries into x86-64 RPM packages. You can just install the 32-bit packages from the 32-bit distribution on a 64-bit system. Adrian
On Fri, Dec 09, 2022 at 05:40:40PM +0100, John Paul Adrian Glaubitz wrote:
On 12/9/22 17:26, Michal Suchánek wrote:
I understand what you mean now. But I'm not sure whether the x86-64 baseline with the limited set of registers on i386 will bring you any remarkable benefit.
Hard to tell without measurements. Still SSE does give you extra registers so it should help especially for 32bit where the base registers are limited.
Sure, some benefit will be there. But I doubt it's really measurable.
Nonetheless, we *do* intend to still provide a 32bit port, and unless the 32bit libraries are to be built twice they should be built for the 32bit architecture we provide as the LegacyX86 port.
Well, if you repackage 32-bit binaries into x86_64, you're not going to install them on a pure 32-bit system are you?
But if you repackage them as 64bit packages that means that they were originally 32bit packages installable on a 32bit system. And depending on the way the repositories are structured they may be also made released for installation on 32bit systems. Thanks Michal
On 09.12.2022 19:53, Michal Suchánek wrote:
On Fri, Dec 09, 2022 at 05:40:40PM +0100, John Paul Adrian Glaubitz wrote:
On 12/9/22 17:26, Michal Suchánek wrote:
I understand what you mean now. But I'm not sure whether the x86-64 baseline with the limited set of registers on i386 will bring you any remarkable benefit.
Hard to tell without measurements. Still SSE does give you extra registers so it should help especially for 32bit where the base registers are limited.
Sure, some benefit will be there. But I doubt it's really measurable.
Nonetheless, we *do* intend to still provide a 32bit port, and unless the 32bit libraries are to be built twice they should be built for the 32bit architecture we provide as the LegacyX86 port.
Well, if you repackage 32-bit binaries into x86_64, you're not going to install them on a pure 32-bit system are you?
But if you repackage them as 64bit packages that means that they were originally 32bit packages installable on a 32bit system. And depending on the way the repositories are structured they may be also made released for installation on 32bit systems.
This doubles space requirement, this needs additional processing to maintain repositories. While being able to simply install 32 bit package on 64 bit system avoids all these extras.
On Fri, Dec 09, 2022 at 07:59:27PM +0300, Andrei Borzenkov wrote:
On 09.12.2022 19:53, Michal Suchánek wrote:
On Fri, Dec 09, 2022 at 05:40:40PM +0100, John Paul Adrian Glaubitz wrote:
On 12/9/22 17:26, Michal Suchánek wrote:
I understand what you mean now. But I'm not sure whether the x86-64 baseline with the limited set of registers on i386 will bring you any remarkable benefit.
Hard to tell without measurements. Still SSE does give you extra registers so it should help especially for 32bit where the base registers are limited.
Sure, some benefit will be there. But I doubt it's really measurable.
Nonetheless, we *do* intend to still provide a 32bit port, and unless the 32bit libraries are to be built twice they should be built for the 32bit architecture we provide as the LegacyX86 port.
Well, if you repackage 32-bit binaries into x86_64, you're not going to install them on a pure 32-bit system are you?
But if you repackage them as 64bit packages that means that they were originally 32bit packages installable on a 32bit system. And depending on the way the repositories are structured they may be also made released for installation on 32bit systems.
This doubles space requirement, this needs additional processing to maintain repositories. While being able to simply install 32 bit package on 64 bit system avoids all these extras.
Unfortunately, our packaging infrastructure is not up to the task. It's not like it's an unsolvable problem, some distributions did solve it. It requires changing the %_libdir on *all* architectures, though. Thanks Michal
As I said, I'm more a fan of the MultiArch approach as it avoids the whole effort of repackaging 32-bit binaries into x86-64 RPM packages. You can just install the 32-bit packages from the 32-bit distribution on a 64-bit system. What's the technical reason MultiArch works on Fedora but not on Tumbleweed?
On Fri, Dec 09, 2022 at 05:01:59PM -0000, Bruno Pitrus wrote:
As I said, I'm more a fan of the MultiArch approach as it avoids the whole effort of repackaging 32-bit binaries into x86-64 RPM packages. You can just install the 32-bit packages from the 32-bit distribution on a 64-bit system. What's the technical reason MultiArch works on Fedora but not on Tumbleweed?
%_libdir conflict between architectures, basically. Also stuffing libraries with other files into a package (which is somewhat discouraged but not uncommon). Some packages might have architecture-specific files that are neither libraries nor executables which needs to be resolved on case-by-case basis. Thanks Michal
John Paul Adrian Glaubitz wrote:
On 12/9/22 17:26, Michal Suchánek wrote:
I understand what you mean now. But I'm not sure whether the x86-64 baseline with the limited set of registers on i386 will bring you any remarkable benefit. Hard to tell without measurements. Still SSE does give you extra registers so it should help especially for 32bit where the base registers are limited. Sure, some benefit will be there. But I doubt it's really measurable.
SSE and SSE2 are parts of x86 architecture. https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions https://en.wikipedia.org/wiki/SSE2 Pentium III gets ~70% speed-up with SSE for fp32-intensive calculations (AMD CPUs in that time gets ~100% because of slow FPU). Pentium 4 gets ~30% speed-up with SSE2. I hope that Tumbleweed 32-bit x86 is using i686 + SSE for compilation. IMHO it is possible to use i686 + SSE + SSE2 for code that will be used in 64-bit OSes. Hint for Tumbleweed x86 supporters: some code contains SSE2 instructions. Read more here: https://forums.opensuse.org/showthread.php/570815-Who-needs-i586-TW-for-CPUs... I hope to get x86-64-v3 Tumbleweed & Leap both in the nearest future. Suggestion for x86-64-v4: add AVX-512 instructions {VPOPCNTDQ, IFMA, VBMI, VBMI2, BITALG, VNNI, VPCLMULQDQ, GFNI, VAES} that is used in Ice Lake, Tiger Lake, Rocket Lake, Zen4. https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX-512
Nonetheless, we *do* intend to still provide a 32bit port, and unless the 32bit libraries are to be built twice they should be built for the 32bit architecture we provide as the LegacyX86 port. they're going to be built twice anyway if LegacyX86 is to be split as a separate project. This is precisely why i suggested adding `-march=x86-64 -mtune=generic` to the 32-bit factory optflags when the ix86 systems support gets dropped from the main repo.
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
Am Freitag, 9. Dezember 2022, 13:47:41 CET schrieb Dirk Müller:
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.
I can only vehemently agree with this, and even if it doesn't look so good at first, this step proves a lot, and especially that common sense can still prevail over any misguided marketing strategies.
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 actory:Rings:1-MinimalX
Nice apart from some of those ugly build issues.
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)
This is exactly the most promising approach, and the only one that really makes sense at this point.
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.
We're on a complicated territory here, and it will take a lot of time and effort to get this sorted out. The new optimizations highly depend on the CPU and the compiler in use. ANd some AMD optimizations for gcc are queued up. But with this structure in place, we (eventually) have the basis to start optimizing current CPU and system architectures, and can regain some of the advantages that distinguish Clear Linux so far... Cheers, Pete -- Life without chameleons is possible, but pointless.
participants (12)
-
Andrei Borzenkov -
Bruno Pitrus -
Dirk Müller -
Dominique Leuenberger / DimStar -
Felix Miata -
Hans-Peter Jansen -
Hartmut Rosch -
John Paul Adrian Glaubitz -
Marcus Meissner -
Michal Suchánek -
Nikolai Nikolaevskii -
Richard Biener