---------- Forwarded message ---------- From: Per Øyvind Karlsen <[email protected]> Date: 2015-06-12 17:02 GMT+02:00 Subject: Re: [OM Cooker] [om-general] Community poll about i586 - have your say! To: Giuseppe Ghibò <[email protected]>
Another argument for keeping i586 port is that x86_64 has eliminated virtual mode, ie. i586 build of dosbox is way faster than x86_64 because of this... Also do not forget that people who care about performance, multimedia etc., would most likely not have legacy hardware, so 5-15% would be hugely irrelevant to most of those people. (btw. while some i586 has mmx support, pentium pro has not) Fedora (likely others also, like Ubuntu) has switched to -march=i686 -mtune=atom, I've changed our to -march=i586 -mtune=atom for a while back, so where Fedora doesn't offer an option for legacy hardware (very common in third world countries, schools etc.), we do offer, which allows us to fill a niché market. These i586 class systems still do a good enough job for personal servers, routers, terminal clients (especially think of schools) etc. So offering a merely 5-15% performance increase for systems who are such low performance to begin with, doesn't offer much appeal to users. List of processors without cmov that my research came across: Intel Pentium Intel Pentium MMX Intel Atom Diamonville Intel Atom Silverthorne Intel Atom Linthorne Intel Atom Penwell A few more Intel Atom 32 bit AMD K5 AMD K6 AMD K6-2 AMD K6-3 AMD Geode series: (ie. OLPC, and various others) AMD GeodeGXm AMD GeodeGXLV AMD GeodeGX1 AMD GeodeGX2 AMD GeodeLX (In 2009, comments by AMD indicated that there are no plans for any future micro architecture upgrades to the processor and that there will be no successor; however, the processors will still be available with the planned availability of the Geode LX extending through 2015) Cyrix Cx5x86 Cyrix 6x86 Cyrix MediaGX Cyrix MediaGXi Cyrix MediaGXm Via C3 (which have interesting features such as low power consumption and heat generation, also hardware accelerated random number generator) Via C7(?) (Hardware support for SHA-1 and SHA-256, hardware based "Montgomery multiplier" supporting key sizes up to 32K for public-key cryptography) Via Eden Via Eden ESP Via Eden-N Via Eden ULV WinChip C6 WinChip 2 WinChip 2A WinChip 2B WinChip 3 Nexgen Nx586 Rise mP6 Vortex86 Vortex86SX Vortex86EX2 Vortex86MX+ Vortex86DX Vortex86DX2 Notice that several of these cpus, especially like the Via, Geode etc. are still popular for embedded and for media centers as well due to VPU hardware acceleration etc... So please leave as is, i586 compatibility is a feature offered which less and less others do, while i686 offers a meager 5-15% performance increase on systems that far fewer people have interest in. 2015-06-10 23:16 GMT+02:00 Giuseppe Ghibò <[email protected]>: > 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]>: > >> 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
