Well, if they did drop the i686 ISO images, then this shouldn't be that controversial, I mean since they'd be used in multilib anyway. I'm partial to this since i686 is already not "i386" (i.e. so it supports stuff like cmov and other such basic instructions) so it's not like their packages were already "maximally compatible" with old CPUs.
Note that, to me, compatibility with 32-bit (or any) software is way more important than old cpu compatibility, so I don't see this as a problem at all (I'm aware some people will tho). Since they will retain compatibility and in fact even make it run a bit faster perhaps. It's not just about the old cpus when it's about 32-bit, the software can also use even AVX and such (albeit less registers than on x64 mode) though most people seem to think it must necessarily be i386 only.
Another solution would be runtime dispatching of functions, but I guess that would bloat some things up (i.e. one path for x87, another for SSE2, ...). And yeah, 32-bit code is friendlier to cache, also data structures using a lot of pointers. Remember that cache space wastes a large amount of the CPU die, so it's pretty important.
-
32-bit x86 code is also somewhat smaller, which is better for 1M caches on some dual-core systems and of course consumes less RAM on systems with <4GB in total. Also most systems since 2001 support SSE2. Plain i686 covers the machines produced between 1995-2001. Those usually had less than one gigabyte of RAM (most likely 64 to 384 MB).Originally posted by davidbepo View PostLast edited by caligula; 04 June 2018, 11:47 AM.Leave a comment:
-
Fedora 29 Proposal "i686 Is For x86-64" Would Allow More Optimizations, Require SSE2
Phoronix: Fedora 29 Proposal "i686 Is For x86-64" Would Allow More Optimizations, Require SSE2
For years Fedora has been demoting 32-bit x86 and there's been efforts to drop 32-bit kernel builds and related efforts while the latest x86 proposal causing some controversy is the "i686 is for x86-64" feature proposal...
Leave a comment: