On 09/06/2015 08:18, Per Øyvind Karlsen wrote: > we've have already had this discussion several times in the past, > first about i686 related to turbolinux, then later on a couple of > times a couple of years ago or so... > > 5-15% performance increase on legacy hardware isn't really noticable > for end users (I've changed to -mtune=atom btw., should help), while > i585 compatibility is still a niché feature that fewer and fewer > others are supporting. > > Being a distro that supports i586 was the argument back then for keep > supporting it due to still several both old (and usable, ie. like via > c3) and some new cpus lack cmov instruction, while in third world > countries i586 are still common, ie. especially think of schools etc. > where they make perfect terminal clients for a more terminal server. > Killing it off, kills of potential market... > > So I *INSIST* on keeping it, discard the i586 port and I'll take > whatever means to prevent it. > > And why the fuck do you have polls on this through OMA? > OMA is not involved with the distro development, that should be pretty > fucking clear by now! > If anything, this poll should merely be a poll and nothing but a poll > just to give some overview and act as an indicator to developers of > popularity.. > > cooker should be the place to make this decission, shouldn't this have > been made clear several times over the past couple of years?? > Hijacking the project two weeks after it was made ultimately clear > proved it not to be, but OMA should have been made clear of this grand > mistake by then... > > If not, you'll just wither and die... > > -- > Regards, > Per Øyvind > > 2015-06-08 15:06 GMT+02:00 Nicolò Costanza <[email protected] > <mailto:[email protected]>>: > > In my opinion, the 32bit is necessary and mandatory still for few > year, > the i686 support is good for over 99% of 32bit users, and the best > it's a bit faster than i586 especially in the multimedia field... > > (I am saying all that from my experience of MIB with Mandriva upto > 2011, where all our packages stored into MIB repositories for > 32bit were: i686 only rebuilt, also my Kernels were all i686, and > noone of our 32bit users had any problems with i686 arch in their > 32bit PCs, as results we had results like from 5 to 15% faster > than i586) > > More: a move from i586 to i686 would be perceived as an > improvement and a progress! > > (i686 is working fine and better in the 99%, and likely more, of > all 32bit PCs, > the i586 only capable cpus are hardly findable and are rather like > a whitefly) > >
Actually we can distinguish a few categories where 32bit are used. 1) old i586 (those have MMX). 2) plain i686 (this is Pentium II, PentiumPro, Pentium III) with MMX and SSE. 3) i686 with SSE2. What really would be worthwhile here and what is really giving some burst (e.g. having something perceivable in video playback) is to support in 32bit the -msse -msse2 -mfpmath=sse flagset as standard math (this is also enabled by default in the x86_64 compiler). This is basically a Pentium 4 of 2000 and beyond (15 years old). Most of old AMD CPUs support MMX, 3DNOW, and even SSE, but not SSE2. 4) Atom. Most of atoms supports even x86_64 set as well as up to SSE3 or beyond. IIRC (but don't take this as written in stone) the only problem of atoms is that they don't support "out of order execution" which is basically enabled in every 32bit arch. So in atom while even running the x86_64 mode is better than i586 (apart the increased memory requirement) the lack of out of order execution (which is automatically enabled in x86_64 compiler) is penalizing. That's why specific 32bit Athlon optimization could (but also with the SSE and SSE2) be worthwhile (i'd like to see some benchmark here where also the glibc is optimized with the same flags). Of course disabling out of order (admitting would be possible) would be penalizing for the CPUs supporting it. 5) cmov or not cmov. 6) Emulators and virtual machines. Using 32bit OSes have sense TODAY in a virtualized enviroment where you want to save some memory. E.g. you might have a lot of tiny VMs running at the same time with minimal memory impact. But those VMs usually tipically runs on recent CPUs, which is very rare not having the SSE2 set. Another problem is the memory impact. While for instance I've a dual CPU motherboard based on Pentium III Coppermine, with 1GB memory (so 1GB was possible there), but most of old CPUs runs with at most 128 or 256MB of memory. I wonder if with such quantity of memory even the installer would start. Has someone measured (e.g. in a Virtual Machine) what is the mimimal amount of memory required to run the installer? Agreed that one can setup a terminal environment there with a tiny X11 without a desktop toolkit, but the 2nd problem comes with the graphic card. Most of old cards of that age (e.g. S3 Virge, Matrox Millennium) for which we still compile and provide the drivers, aren't working at all with that drivers anymore. Note that I'm not saying of killing any i586, this or that, support. Bye. Giuseppe.
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
