[opensuse-factory] Changing Architecture level for 32bit x86 to x86-64
SLES 15 will change the architecture level for 32bit x86 package builds to x86-64 to match the 64bit x86 builds as the only use for the 32bit packages are to run on a 64bit SLES install. I propose to do the same for Tumbleweed. Requiring x86-64 means (ontop of the current i586 level) requiring MMX, SSE, SSE2 and FXSR. That cuts off (from a look at GCC internals) CPUs with nickname pentium-mmx, c3-2, i686, pentiumpro pentium2 pentium3, pentium3m, geode, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4, athlon-xp, athlon-mp. Most of those will have difficulties running Tumbleweed due to low memory (I remember my Athlon box having 16MB of ram which was plenty at the time). Advantages of raising the architecture level is better performance of 32bit applications on 64bit and a simpler repository setup (no more glibc.i686). Bonus points for somebody finding a table mapping architecture features to products rather than the other way around. Thus - check your /proc/cpuinfo for the lack of MMX/SSE/SSE2/FXSR and report back. Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2017-08-15 at 11:53 +0200, Richard Biener wrote:
SLES 15 will change the architecture level for 32bit x86 package builds to x86-64 to match the 64bit x86 builds as the only use for the 32bit packages are to run on a 64bit SLES install.
I propose to do the same for Tumbleweed.
So you basically send our 32bit users (i586) away - what do we actually WIN by this?
Requiring x86-64 means (ontop of the current i586 level) requiring MMX, SSE, SSE2 and FXSR.
That cuts off (from a look at GCC internals) CPUs with nickname pentium-mmx, c3-2, i686, pentiumpro pentium2 pentium3, pentium3m, geode, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4, athlon-xp, athlon-mp. Most of those will have difficulties running Tumbleweed due to low memory (I remember my Athlon box having 16MB of ram which was plenty at the time).
A i686 with a couple GB of ram is nothing special I'd say.
Advantages of raising the architecture level is better performance of 32bit applications on 64bit and a simpler repository setup (no more glibc.i686).
Bonus points for somebody finding a table mapping architecture features to products rather than the other way around.
Thus - check your /proc/cpuinfo for the lack of MMX/SSE/SSE2/FXSR and report back.
Sadly, we will not get a feedback from all machines running TW - so we frankly have no idea what machine will 'stop working from one day to another' Of course this is no issue for SLE/Leap, where there is simply no i586 support - I see it slightly different for TW and before accepting any such thing, we should get an understanding of what we break and how many users/machines we 'send away' Cheers, Dominique
Hi Dominique, On 15.08.2017 15:41, Dominique Leuenberger / DimStar wrote:
On Tue, 2017-08-15 at 11:53 +0200, Richard Biener wrote:
SLES 15 will change the architecture level for 32bit x86 package builds to x86-64 to match the 64bit x86 builds as the only use for the 32bit packages are to run on a 64bit SLES install.
I propose to do the same for Tumbleweed.
So you basically send our 32bit users (i586) away - what do we actually WIN by this?
Only very few people are actually using i586, most are using later i686 processors.
Requiring x86-64 means (ontop of the current i586 level) requiring MMX, SSE, SSE2 and FXSR.
That cuts off (from a look at GCC internals) CPUs with nickname pentium-mmx, c3-2, i686, pentiumpro pentium2 pentium3, pentium3m, geode, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4, athlon-xp, athlon-mp. Most of those will have difficulties running Tumbleweed due to low memory (I remember my Athlon box having 16MB of ram which was plenty at the time).
A i686 with a couple GB of ram is nothing special I'd say.
These machines (pentium M dothan machines for example) will not be discontinued IIUC, only earlier machines (pentium3 with less than ~1GHz and probably a few Athlon class with less than ~1.5GHz CPU frequency).
Advantages of raising the architecture level is better performance of 32bit applications on 64bit and a simpler repository setup (no more glibc.i686).
Bonus points for somebody finding a table mapping architecture features to products rather than the other way around.
Thus - check your /proc/cpuinfo for the lack of MMX/SSE/SSE2/FXSR and report back.
Sadly, we will not get a feedback from all machines running TW - so we frankly have no idea what machine will 'stop working from one day to another'
Of course this is no issue for SLE/Leap, where there is simply no i586 support - I see it slightly different for TW and before accepting any such thing, we should get an understanding of what we break and how many users/machines we 'send away'
People who really need to use such old and (for todays standards) very low powered hardware are likely to not use openSUSE on them anyway but instead will probably be looking into custom embedded-class distributions / meta-distributions (Yocto poky anyone?) already. I'm all for keeping the old stuff working, but on the other hand I could not even be bothered to boot my old Pentium M dothan class machiens for over a year, even less try if current TW still runs, so I can understand why Richard from a "reduce complexity" standpoint wants to get rid of the old stuff and concentrate on the machines that are actually used by people. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dominique Leuenberger / DimStar píše v Út 15. 08. 2017 v 15:41 +0200:
On Tue, 2017-08-15 at 11:53 +0200, Richard Biener wrote:
SLES 15 will change the architecture level for 32bit x86 package builds to x86-64 to match the 64bit x86 builds as the only use for the 32bit packages are to run on a 64bit SLES install. I propose to do the same for Tumbleweed.
So you basically send our 32bit users (i586) away - what do we actually WIN by this?
Requiring x86-64 means (ontop of the current i586 level) requiring MMX, SSE, SSE2 and FXSR.
That cuts off (from a look at GCC internals) CPUs with nickname pentium-mmx, c3-2, i686, pentiumpro pentium2 pentium3, pentium3m, geode, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4, athlon-xp, athlon-mp. Most of those will have difficulties running Tumbleweed due to low memory (I remember my Athlon box having 16MB of ram which was plenty at the time).
A i686 with a couple GB of ram is nothing special I'd say.
Advantages of raising the architecture level is better performance of 32bit applications on 64bit and a simpler repository setup (no more glibc.i686). Bonus points for somebody finding a table mapping architecture features to products rather than the other way around.
Thus - check your /proc/cpuinfo for the lack of MMX/SSE/SSE2/FXSR and report back.
Sadly, we will not get a feedback from all machines running TW - so we frankly have no idea what machine will 'stop working from one day to another'
Of course this is no issue for SLE/Leap, where there is simply no i586 support - I see it slightly different for TW and before accepting any such thing, we should get an understanding of what we break and how many users/machines we 'send away'
Actually this is false positive. Even if the box work on i586 right now we state in documentation minimal machine is pentium 4 with all the features. Which means sse2 and fun. Thus we already exclude them. It keeps to work by accident and then people are suprised that suddenly fips check start to break stuff... Also this has lovely benefit of speeding all the 32bit stuff like steam for 64bit users, so by this you are saying that you preffer 12y+ old hw over the current one. Actually the wiki is even more fun https://en.opensuse.org/Hardware_req uirements we state the p4 as minimum for Leap while it is not possible to run on 32bit... :) Tom
On Tuesday 2017-08-15 16:53, Tomas Chvatal wrote:
Thus - check your /proc/cpuinfo for the lack of MMX/SSE/SSE2/FXSR and report back.
Of course this is no issue for SLE/Leap, where there is simply no i586 support - I see it slightly different for TW and before accepting any such thing, we should get an understanding of what we break and how many users/machines we 'send away'
Actually this is false positive. Even if the box work on i586 right now we state in documentation minimal machine is pentium 4 with all the features. Which means sse2 and fun. Thus we already exclude them.
It keeps to work by accident and then people are suprised that suddenly fips check start to break stuff...
Also this has lovely benefit of speeding all the 32bit stuff like steam for 64bit users, so by this you are saying that you preffer 12y+ old hw over the current one.
Please back your claim up by numbers. The important parts, such as glibc, should be using run-time detection already. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 15 Aug 2017, Jan Engelhardt wrote:
On Tuesday 2017-08-15 16:53, Tomas Chvatal wrote:
Thus - check your /proc/cpuinfo for the lack of MMX/SSE/SSE2/FXSR and report back.
Of course this is no issue for SLE/Leap, where there is simply no i586 support - I see it slightly different for TW and before accepting any such thing, we should get an understanding of what we break and how many users/machines we 'send away'
Actually this is false positive. Even if the box work on i586 right now we state in documentation minimal machine is pentium 4 with all the features. Which means sse2 and fun. Thus we already exclude them.
It keeps to work by accident and then people are suprised that suddenly fips check start to break stuff...
Also this has lovely benefit of speeding all the 32bit stuff like steam for 64bit users, so by this you are saying that you preffer 12y+ old hw over the current one.
Please back your claim up by numbers. The important parts, such as glibc, should be using run-time detection already.
Recently 'gd' came up as an example which has a configure test whether it can enable -mfpmath=sse (which it can with -march=x86-64 but not with -march=i586). I suspect there are quite some packages that might benefit. Note that it is not necessarily breaking support for older machines either as not all packages will end up magically using SSE2 -- if they stay with our default RPM_OPT_FLAGS they actually will not. FXSR is a sligtly different issue but also supported by older CPUs (those that have SSE but not SSE2 from a quick look). Note that Leap 15 will (likely) have this change so it's going to be somewhat odd that Tumbleweed doesn't. Still waiting for somebody to confirm he's actually running such old machine on Tumbleweed ;) Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 15.08.2017 um 17:56 schrieb Richard Biener:
On Tue, 15 Aug 2017, Jan Engelhardt wrote:
On Tuesday 2017-08-15 16:53, Tomas Chvatal wrote:
Thus - check your /proc/cpuinfo for the lack of MMX/SSE/SSE2/FXSR and report back.
Note that Leap 15 will (likely) have this change so it's going to be somewhat odd that Tumbleweed doesn't.
Still waiting for somebody to confirm he's actually running such old machine on Tumbleweed ;)
Richard.
Hi, I'm running Tumbleweed on a laptop, built in 2005, with a 32bit only Pentium-M-cpu from 2004 (2GB RAM). But it supports all the required features like sse2. So personally I don't mind the change. Hendrik -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Biener composed on 2017-08-15 17:56 (UTC+0200):
Still waiting for somebody to confirm he's actually running such old machine on Tumbleweed ;)
Host & CPU Socket type: a-865 478 gx110 370 (P3, no sse2) (last updated >1year ago) gx150 370 (P3, no sse2) gx260 478 gx270 478 gx27b 478 gx27c 478 gx280 478 gx28b 478 gx28c 478 hs80e (external floater) (last updated >1year ago) kt400 462 (Athlon XP, no sse2) kt88b 462 (Athlon XP, no sse2) m7ncd 462 (Sempron, no sse2) t2240 478 15 total, 13 "active" Pentium 4 motherboards with Socket 478 cannot be upgraded to 64-bit CPUs. 478 motherboards typically support no more than 2GB RAM. Recent thread here that may indicate other users or would-be users using TW because 32-bit was dropped from "Distribution" releases: https://lists.opensuse.org/opensuse-factory/2017-08/msg00105.html -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 15 Aug 2017, Felix Miata wrote:
Richard Biener composed on 2017-08-15 17:56 (UTC+0200):
Still waiting for somebody to confirm he's actually running such old machine on Tumbleweed ;)
Host & CPU Socket type: a-865 478 gx110 370 (P3, no sse2) (last updated >1year ago) gx150 370 (P3, no sse2) gx260 478 gx270 478 gx27b 478 gx27c 478 gx280 478 gx28b 478 gx28c 478 hs80e (external floater) (last updated >1year ago) kt400 462 (Athlon XP, no sse2) kt88b 462 (Athlon XP, no sse2) m7ncd 462 (Sempron, no sse2) t2240 478
15 total, 13 "active"
Pentium 4 motherboards with Socket 478 cannot be upgraded to 64-bit CPUs. 478 motherboards typically support no more than 2GB RAM.
Note that Pentium 4 is safe, so from your list above that is 5 machines left behind (not sure about hs80e), two of them updated >1year ago. What do those machines actually do?
Recent thread here that may indicate other users or would-be users using TW because 32-bit was dropped from "Distribution" releases: https://lists.opensuse.org/opensuse-factory/2017-08/msg00105.html
Yes, I saw that. I'm not suggesting to drop 32bit, I'm just suggesting to drop support for CPUs that are very old. Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2017-08-16 09:29, Richard Biener wrote:
Recent thread here that may indicate other users or would-be users using TW because 32-bit was dropped from "Distribution" releases: https://lists.opensuse.org/opensuse-factory/2017-08/msg00105.html
Yes, I saw that. I'm not suggesting to drop 32bit, I'm just suggesting to drop support for CPUs that are very old.
I wonder why IA-32 (on a 64-bit CPU, mind you - since that's your SLE use case) suddenly is so important that fpmath=sse needs to be turned on. If it is, can't the few IA-32 packages be built as another offering? Declare %optflags pentium4 in the prjconf, make pentium4 a recognized zypper and OBS scheduler architecture value, enter it into mkbaselibs, and then let `rpmbuild --target=pentium4` work its magic (because rpm can already do that). It's what these things are for IMO. (See also: rpm's ppc64 <-> ppc64p7, sparc64 <-> sparc64v, ...) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On August 16, 2017 7:08:21 PM GMT+02:00, Jan Engelhardt <jengelh@inai.de> wrote:
On Wednesday 2017-08-16 09:29, Richard Biener wrote:
Recent thread here that may indicate other users or would-be users
using TW
because 32-bit was dropped from "Distribution" releases: https://lists.opensuse.org/opensuse-factory/2017-08/msg00105.html
Yes, I saw that. I'm not suggesting to drop 32bit, I'm just suggesting to drop support for CPUs that are very old.
I wonder why IA-32 (on a 64-bit CPU, mind you - since that's your SLE use case) suddenly is so important that fpmath=sse needs to be turned on.
I am not aware of anybody wanting to force fpmath=sse to be the default.
If it is, can't the few IA-32 packages be built as another offering? Declare %optflags pentium4 in the prjconf, make pentium4 a recognized zypper and OBS scheduler architecture value, enter it into mkbaselibs, and then let `rpmbuild --target=pentium4` work its magic (because rpm can already do that).
It's what these things are for IMO. (See also: rpm's ppc64 <-> ppc64p7, sparc64 <-> sparc64v, ...)
We're trying to remove complexity, not add. Richard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2017-08-15 17:56, Richard Biener wrote:
It keeps to work by accident and then people are suprised that suddenly fips check start to break stuff...
Also this has lovely benefit of speeding all the 32bit stuff like steam for 64bit users, so by this you are saying that you preffer 12y+ old hw over the current one.
Please back your claim up by numbers. The important parts, such as glibc, should be using run-time detection already.
Recently 'gd' came up as an example which has a configure test whether it can enable -mfpmath=sse (which it can with -march=x86-64 but not with -march=i586). I suspect there are quite some packages that might benefit.
Well ok, so that's *that* kind of speedup, i.e. replacing x87 floating point math like multiply and divide. My number - from the year 2006 - was that vorbis-tools improved by ~17% when enabling (just) SSE1 this way. Then again, are the low-power machines the place where one would (still) do encoding today? :-)
Note that Leap 15 will (likely) have this change so it's going to be somewhat odd that Tumbleweed doesn't.
Still waiting for somebody to confirm he's actually running such old machine on Tumbleweed ;)
I have a working vintage SSE1-only Athlon XP system on an L7S7A2 board with 1536 MB memory installed, which is 2x more than what it was sold with decades ago. I also have a vintage TM5800 system which I recall likely did not have SSE - or either CMOV. I should check which when getting home. Has the system max of 448MB installed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Biener writes:
Thus - check your /proc/cpuinfo for the lack of MMX/SSE/SSE2/FXSR and report back.
The only system I still somewhat care about runs a Tualatin P3 Celeron (Socket 370 via Slot1 adapter card) and it would most definitely be affected since it doesn't have SSE2. I also have a semi-mothballed Sempron in a 754 socket (the AGP graphics card died), but I think it was a new enough stepping so it would actually work. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Achim Gratz -
Dominique Leuenberger / DimStar -
Felix Miata -
Hendrik Woltersdorf -
Jan Engelhardt -
Richard Biener -
Stefan Seyfried -
Tomas Chvatal