[opensuse-factory] Ancient hardware support statement
Hi guys, without checking any mail archives, our forums or wikis for prior art, I would like to know if we have any general hardware support statements. I'm currently staring at a maintenance update that disables SSE2 support on certain software because the CPU doesn't support it. The manufacturing of that CPU stopped in 2004, so I'm not really sure what to think of it. Any thoughts? -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21.10.2013 14:44, Sascha Peilicke wrote:
Hi guys,
without checking any mail archives, our forums or wikis for prior art, I would like to know if we have any general hardware support statements. I'm currently staring at a maintenance update that disables SSE2 support on certain software because the CPU doesn't support it. The manufacturing of that CPU stopped in 2004, so I'm not really sure what to think of it. Any thoughts?
Our documentation says - I bet it was updated last time 2004 ;) 1.2. System Requirements¶ Pentium* III 500 MHz or higher processor (Pentium 4 2.4 GHz or higheror any AMD64 or Intel* EM64T processor recommended) 512 MB physical RAM (1 GB recommended) 3 GB available disk space (more recommended) 800 x 600 display resolution (1024 x 768 or higher recommended) Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFSZSKLwFSBhlBjoJYRAkj8AKCkv6D6B6Jg1JIblM4t7bTSWxxFtgCgidiR cfBfzGFUxjZYaur7yzObKKE= =KwrR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 21 October 2013 14:48:11 Stephan Kulow wrote:
On 21.10.2013 14:44, Sascha Peilicke wrote:
Hi guys,
without checking any mail archives, our forums or wikis for prior art, I would like to know if we have any general hardware support statements. I'm currently staring at a maintenance update that disables SSE2 support on certain software because the CPU doesn't support it. The manufacturing of that CPU stopped in 2004, so I'm not really sure what to think of it. Any thoughts?
Our documentation says - I bet it was updated last time 2004 ;)
1.2. System Requirements¶ Pentium* III 500 MHz or higher processor (Pentium 4 2.4 GHz or higheror any AMD64 or Intel* EM64T processor recommended)
Well, it's an AMD K7 [0] and actually matches these requirements :-) [0] http://www.cpu-world.com/CPUs/K7/AMD-Duron%201800%20-%20DHD1800DLV1C.html -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
El 21/10/13 09:44, Sascha Peilicke escribió:
Hi guys,
without checking any mail archives, our forums or wikis for prior art, I would like to know if we have any general hardware support statements. I'm currently staring at a maintenance update that disables SSE2 support on certain software because the CPU doesn't support it. The manufacturing of that CPU stopped in 2004, so I'm not really sure what to think of it. Any thoughts?
I think that for *new products* we should require SSE2 .. or rather build the complete distro for 686. -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-10-21 14:44 (GMT+0200) Sascha Peilicke composed:
without checking any mail archives, our forums or wikis for prior art, I would like to know if we have any general hardware support statements. I'm currently staring at a maintenance update that disables SSE2 support on certain software because the CPU doesn't support it. The manufacturing of that CPU stopped in 2004, so I'm not really sure what to think of it. Any thoughts?
These are cpuinfo from 3 of my dozen or so routine testing systems: model name : AMD Athlon(tm) XP 2000+ cpu MHz : 1674.292 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up bogomips : 3348.58 address sizes : 34 bits physical, 32 bits virtual model name : AMD Athlon(tm) XP 2400+ cpu MHz : 2000.101 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up bogomips : 4000.20 address sizes : 34 bits physical, 32 bits virtual model name : AMD Sempron(tm) 2800+ cpu MHz : 1996.334 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow up bogomips : 3992.66 address sizes : 34 bits physical, 32 bits virtual All three are quite adequate for email, web browsing, bookkeeping and writing letters. Machines used for similar purposes shouldn't be forced into retirement or made subject to attack due to age. It's bad for the environment, and downright wasteful. All three of this list are seriously old designs, but only one is actually more than 10 years old. The 2 newest motherboards and newest CPU were new in box (old stock) only 7 years ago. -- "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 Monday 2013-10-21 14:44, Sascha Peilicke wrote:
I would like to know if we have any general hardware support statements. I'm currently staring at a maintenance update that disables SSE2 support on certain software because the CPU doesn't support it. The manufacturing of that CPU stopped in 2004, so I'm not really sure what to think of it. Any thoughts?
Are you talking about the devel:libraries:c_c++/xerces-c case? I don't know what was going on there, because Hrvoje did not bother to add an explanation into the .spec as to _why_ SSE2 got disabled (nor is the bug report accessible) other than just telling us "the (SLE) customer says this fixes it". Fixes what? Now, the general support statement is "i586", and the definition of i586 means it has to cope without SSE,AVX, etc. Where I see problems: 1. software that inserts -march=native into the command line after our CFLAGS 2. software that inserts -mmmx, -msse/2/3, -mavx unconditionally 3. openSUSE prjconf lacks specifying -mno-mmx, -mno-sse etc. (but so far we have not needed that) 4. software that runs SSE assembler lines without checking CPUID In case #1, we would edit the Makefilery to not override user CFLAGS and then send it to the upstream maintainer, and the story ends. In case #4, which occurs at times, such as in /games/zdbsp - and which is probably also the reason for xerces-c - we just disable MMX/SSE/etc. for i586. Or, if $editor has the patience, makes a patch to put a cpuid check around it, like software {ought to do it and normally does}. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2013-10-22 16:24, Jan Engelhardt wrote:
Where I see problems:
1. software that inserts -march=native into the command line after our CFLAGS 2. software that inserts -mmmx, -msse/2/3, -mavx unconditionally 3. openSUSE prjconf lacks specifying -mno-mmx, -mno-sse etc. (but so far we have not needed that) 4. software that runs SSE assembler lines without checking CPUID [...] In case #4, which occurs at times, such as in /games/zdbsp[...] we just disable MMX/SSE/etc. for i586.
Everybody note that this is not a problem specific to i586. x86_64 only specifies the set of {MMX,SSE,SSE2}. Once software pops up that unconditionally includes or runs AVX, FM3/FM4, you will eventually have to write %configure \ %ifarch x86_64 %ix86 --disable-avx %endif It is not even limited to x86ish. Think %configure \ %ifarch sparc64 --disable-vis3 # T4 and up %endif %configure \ %ifarch ppc ppc64 --disable-vsx # POWER7 and up %endif (or make a cpuid-testing patch). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> wrote:
x86_64 only specifies the set of {MMX,SSE,SSE2}. Once software pops up that unconditionally includes or runs AVX, FM3/FM4, you will eventually have to write
%configure \ %ifarch x86_64 %ix86 --disable-avx %endif
It is not even limited to x86ish. Think
%configure \ %ifarch sparc64 --disable-vis3 # T4 and up %endif %configure \ %ifarch ppc ppc64 --disable-vsx # POWER7 and up %endif (or make a cpuid-testing patch).
Is there nothing like isainfo in Linux? isainfo -v 64-bit amd64 applications xsave sse4.1 ssse3 cx16 sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu 32-bit i386 applications xsave sse4.1 ssse3 ahf cx16 sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2013-10-22 17:14, Joerg Schilling wrote:
Is there nothing like isainfo in Linux?
isainfo -v 64-bit amd64 applications xsave sse4.1 ssse3 cx16 sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu 32-bit i386 applications xsave sse4.1 ssse3 ahf cx16 sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu
We have /proc/cpuinfo. But how does that relate to the compilation of programs? flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> wrote:
On Tuesday 2013-10-22 17:14, Joerg Schilling wrote:
Is there nothing like isainfo in Linux?
isainfo -v 64-bit amd64 applications xsave sse4.1 ssse3 cx16 sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu 32-bit i386 applications xsave sse4.1 ssse3 ahf cx16 sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu
We have /proc/cpuinfo. But how does that relate to the compilation of programs?
Well, when you comppile, you could use: -xarch=generic to go back to a minimum set -xarch=native to use everything the current CPU supports - something special handrafted. ... When executing programs, you usually make a hard link to /usr/lib/isaexec and this program is a one MMU page sized thing that calls sysinfo(SI_ISALIST, and looks for machine specific binaries.... isalist amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 The program to call is searched in a subdirectory of the hardlink using the isalist output as directory names. libc is mounted to the best fit libc compile variant for performance reasons. BTW: this appeared in 1997, when 64 bit support was added to Solaris. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2013-10-22 18:06, Joerg Schilling wrote:
Jan Engelhardt <jengelh@inai.de> wrote:
On Tuesday 2013-10-22 17:14, Joerg Schilling wrote:
Is there nothing like isainfo in Linux?
We have /proc/cpuinfo. But how does that relate to the compilation of programs?
Well, when you comppile, you could use:
-xarch=generic to go back to a minimum set -xarch=native to use everything the current CPU supports - something special handrafted.
We must always compile with the minimum set because we do not know what the target machine will be like. gcc -march=i586 does that (for openSUSE's definition of "minimum"). But as portrayed in previous mails, compiler switches don't help if you have a __asm__("pmovsomething %xmmwhatever..."); or equivalent.
libc is mounted to the best fit libc compile variant for performance reasons. BTW: this appeared in 1997, when 64 bit support was added to Solaris.
In glibc, all the accelerated codes live within (the one) libc.so, and ld.so resolves symbols like strchr to __strchr_sse2 / __strchr_sse42 at program startup through a mechanism that is known as ifunc. That means we do not have to provide the computationally boring parts of libc — such as stdio, which provides one of the largest functions according to readelf — more than once like it would be the case for multiple libc.so files. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> wrote:
We must always compile with the minimum set because we do not know what the target machine will be like. gcc -march=i586 does that (for openSUSE's definition of "minimum").
Correct. A useful minimum default would be a pentium with no fdiv bug.
But as portrayed in previous mails, compiler switches don't help if you have a __asm__("pmovsomething %xmmwhatever..."); or equivalent.
This is a general problem with the quality of OSS. The opcode is not the only problem here, another problem is the assumtion that some vendor-specific non-standard C enhancements may be used with the systems compiler.
libc is mounted to the best fit libc compile variant for performance reasons. BTW: this appeared in 1997, when 64 bit support was added to Solaris.
In glibc, all the accelerated codes live within (the one) libc.so, and ld.so resolves symbols like strchr to __strchr_sse2 / __strchr_sse42 at program startup through a mechanism that is known as ifunc. That means we do not have to provide the computationally boring parts of libc ??? such as stdio, which provides one of the largest functions according to readelf ??? more than once like it would be the case for multiple libc.so files.
Well if you believe that disk space is rare, you are right. If you believe that avoiding to fill RAM with unneeded code is more important, the Solarie method is better. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
<sarcasm> so where i can download this awesome operating system solaris for free, oh i can not? Shame on me i wanna use free (libre) opensource software. I assume windows is also better... oh no source either aaah... Windows and Solaris FTW in actual lingua... </sarcasm> I understand you have direct monetary benefit from Oracle or who ever but if you do not wanna help people/ do not wanna really provide constructive conversations please don't bother answering this email either. Saying Solaris is better than minix / linux / *BSD and we should use it IS NOT CONSTRUCTIVE... I do not mind you write CDDL code for external software (which i do not mind you do and it is good software mki... cdre... and so on) *BUT* Try to be constructive and write or bugfix code even if it is god forbid written with/in GPL. Rants about linux vs solaris way .... really you are older than that Or just enjoy life it is free (for most parts) -- Boris On Wed, Oct 23, 2013 at 12:23 PM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
Jan Engelhardt <jengelh@inai.de> wrote:
We must always compile with the minimum set because we do not know what the target machine will be like. gcc -march=i586 does that (for openSUSE's definition of "minimum").
Correct. A useful minimum default would be a pentium with no fdiv bug.
But as portrayed in previous mails, compiler switches don't help if you have a __asm__("pmovsomething %xmmwhatever..."); or equivalent.
This is a general problem with the quality of OSS.
The opcode is not the only problem here, another problem is the assumtion that some vendor-specific non-standard C enhancements may be used with the systems compiler.
libc is mounted to the best fit libc compile variant for performance reasons. BTW: this appeared in 1997, when 64 bit support was added to Solaris.
In glibc, all the accelerated codes live within (the one) libc.so, and ld.so resolves symbols like strchr to __strchr_sse2 / __strchr_sse42 at program startup through a mechanism that is known as ifunc. That means we do not have to provide the computationally boring parts of libc ??? such as stdio, which provides one of the largest functions according to readelf ??? more than once like it would be the case for multiple libc.so files.
Well if you believe that disk space is rare, you are right. If you believe that avoiding to fill RAM with unneeded code is more important, the Solarie method is better.
Jörg
-- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Boris Manojlovic <boris@steki.net> wrote:
<sarcasm> so where i can download this awesome operating system solaris for free, oh i can not? Shame on me i wanna use free (libre) opensource software. I assume windows is also better... oh no source either aaah... Windows and Solaris FTW in actual lingua... </sarcasm>
For the uninformed people like you: http://hg.berlios.de/repos/schillix-on Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 24 October 2013 12:25:01 Joerg Schilling wrote:
Boris Manojlovic <boris@steki.net> wrote:
<sarcasm> so where i can download this awesome operating system solaris for free, oh i can not? Shame on me i wanna use free (libre) opensource software. I assume windows is also better... oh no source either aaah... Windows and Solaris FTW in actual lingua... </sarcasm>
For the uninformed people like you:
http://hg.berlios.de/repos/schillix-on
Jörg
... and I feel this part of the thread has outlived its useful-ness, could we refrain from sarcastic and condescending emails please? Hugs, Jos
On Wednesday 2013-10-23 12:23, Joerg Schilling wrote:
libc is mounted to the best fit libc compile variant for performance reasons. BTW: this appeared in 1997, when 64 bit support was added to Solaris.
In glibc, all the accelerated codes live within (the one) libc.so, and ld.so resolves symbols like strchr to __strchr_sse2 / __strchr_sse42 at program startup through a mechanism that is known as ifunc. That means we do not have to provide the computationally boring parts of libc ??? such as stdio, which provides one of the largest functions according to readelf ??? more than once like it would be the case for multiple libc.so files.
Well if you believe that disk space is rare, you are right. If you believe that avoiding to fill RAM with unneeded code is more important, the Solarie method is better.
You certainly have a point in that. However, x86 has garnered so many CPU extensions over the years (and so did sparc - e.g. vis, vis2, vis3) that shipping a single library for every possible combination becomes a bit unmanageable. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 22/10/13 12:14, Joerg Schilling escribió:
Is there nothing like isainfo in Linux?
Yes plus compiler/linker infrastructure to make code execute only when certain hardware capabilities exist in the target machine. Unfortunately it was only used by glibc and libstdc++ last time I checked. -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Boris Manojlovic -
Cristian Rodríguez -
Felix Miata -
Jan Engelhardt -
Joerg Schilling -
Jos Poortvliet -
Sascha Peilicke -
Stephan Kulow