On Sun, 20 Oct 2002, Andrew Smith wrote: >Well - having thought about it a bit more ... > >Removing one 12Mb RPM is quite rediculous when almost EVERY other >intel RPM is built for an i386. Even glibc has an i386 version. >If you say that you no longer support i386 - then build all the >RPM's to i586 and be done with it. If every RPM was at least i586 >then all intel machines would run a ilttle bit faster. Actually, you're wrong. The architecture field present in the RPM filename, and header indicates the "instruction set" in use by the binaries inside the package. It means that you need a machine capable of that instruction set, or higher in order to install and use the package. When an RPM package is built with the "--target i686" or whatever option, this translates into the compiler flag "-march=i686" which selects the Intel i686 instruction set. Likewise a target of i586 would tell the compiler to use the i586 instruction set by passing "-march=i586". Choosing a target of i686 means the binaries will not run on any CPU that is not a i686 class machine. Examples of machines that do not have the full i686 instruction set: Pentium, Cyrix (all of them AFAIK except perhaps the latest CPU from them), AMD K5, K6. Using a target of i686 would cut support for all of this hardware, as well as some other CPUs. We support Pentium, K5, K6 class CPU's still however, so building the whole distribution with -march=i686 is not viable in any way shape or form at this point in time. Also, -march=i686 isn't an "all gain" for every single application. One of the biggest gains comes from the CMOV instruction, however most applications do not really benefit directly from CMOV, but rather benefit from CMOV being used in the C libraries. Since we ship glibc in an i686 compiled form, most applications on the whole distribution that could benefit from CMOV, already do, as they're using the i686 optimized glibc at runtime if you have an i686 or higher. With the i686 built glibc, most of the benefits from using -march=i686 are gained simply by using glibc. -march=i586 on the other hand is in a different boat. Choosing this is supposed to enable the i586 instruction set, however the i586 has relatively few new instructions and most of them are pretty worthless for generic code. I've been told by gcc developers that gcc does not use any i586 specific instructions when -march=i586 is chosen. As such, for all intents and purposes, -march=i586 is more or less identical to -march=i386 for everything. That is why there is no i586 built glibc in the distribution, and no i586 built applications. There's no benefit to doing so. The only thing using -march=i586 does in reality, is enable a handful of C macros. If a given application has hand coded assembly language, optimized for i586, and wrapped up in an ifdef block, in this case -march=i586 could enable this code, and the app would run faster. However few apps use assembler at all period, and those that do, tend to include code for all processor variants, and do runtime CPU detection rather than build time detection. In other words, what the documentation says these options do, and what the gcc code has actually implemented in reality are quite different from what most people think is there. The kernel is a special case here, as the kernel has all kinds of per CPU arch build time optimizations, which is why we have an i586 kernel. It's quite special. Virtually zero applications thus benefit from changing -march=i386 to -march=i586. You can test this out, by running a profiler on an application built with -march=i386, and then again with the same app doing the same thing built with -march=i586. There's one other thing -march=i586 does that can be beneficial. Some apps forget to "#include <math.h>" everywhere that it should be properly included. Code which doesn't include math.h properly will build differently with -march=i386 and -march=i586. The solution here however isn't to use -march=i586, but rather to fix the dumb code to properly include the required header files. Any applications which are I/O bound, such as disk intensive or network intensive apps, generally do not benefit from any type of performance optimization via instructions available in newer CPU's. There are likely some exceptions, but the exceptions wont make the rule. There are probably a small handful of applications and/or libraries in the distro which could benefit from -march=i686. One would have to do specific profiling of any potential app or library to see if it truely does benefit from it. Most people's "I can just tell it is better" doesn't cut it really. Scientific measurement is required for this sort of thing. There are likely various things that would benefit. Purely guessing, if someone wanted to try, I'd try rebuilding XFree86, gnome, kde, possibly mozilla, and maybe some other large apps/libs. I would only do one component at a time however, so that it can be properly measured with valid tools. However, to ship i686 packages of things would mean that we need to either only support i686 processors which have the optional CMOV instruction, or else we would have to ship double packages of various things, double our QA efforts, double the space consumed on the CD's (either making the distro larger, or by tossing out more packages to make room for new optimized packages). It just is not feasible IMHO to do any of this for the extremely minor gains that it gives. If a given app, when rebuilt for i686 or whatever processor does in fact have a performance gain, users are free to recompile that RPM for i686 if they like, which is a benefit of having the source code rpm packages. At some point in time in the future, I imagine "Pentium" or otherwise "i586" classified machines will fall into the unsupported area also. Whenever that happens (who knows, could be a long time), then it is feasible to consider building some things for i686 instruction set. It just isn't worth the trouble right now however. >The argument has been stated before that the majority of >performance gain is in using the kernel and glibc that matches >your processor - and that all the rest is more effort than worth >the gain. It's not really an argument, but rather a statement of why things are the way they are. >However, if they all were already i586 then the effort would be >zero to anyone installing to have all to be at least i586 Well, if i586 packages actually differed at all in any useful way from i386 packages, that might hold some water, and I might agree with you. In reality though, it doesn't make any difference as I've stated above. i686 will definitely make a difference for _some_ things, but i586 wont make any difference for anything other than specific apps with ifdef'd i586 stuff or similar as outlined above. So there really is no point. If using i586 across the board in fact was a benefit, we would be using it right now across the board. We would have no reason not to. On a different note, the compiler flag -mcpu=xxx is a different story entirely from -march. While -march chooses the instruction set, and thus minimum required machine, and RPM package arch... -mcpu selects instruction sheduling order. The instruction scheduling order is optimized to run the fastest on the arch you tell it. While the instructions are reordered for the given CPU, they remain valid instructions for the -march supplied. So using -mcpu=i686 optimizes binaries for i686 instruction scheduling. This is the default for all of Red Hat Linux. We use i386 compatible instructions (-march=i386) but our entire distro is optimized for i686 CPU's, by using -mcpu=i686 which optimizes the instruction order for i686. This combination gives the biggest bang for the buck, while maintaining a high level of compatibility. >Secondly, there is no such thing as a height measurement that puts >the lowest pentium above the highest Cyrix 6x86. If a given Cyrix 6x86 processor cannot run one of our supported kernels, then it is unsupported. I don't know about the latest Cyrix CPU's, but previous ones did not have the optional i686 CMOV instruction for example, and though the CPU's are otherwise i686 for the most part, not having CMOV disqualifies them from being i686 from the perspective of rpm/gcc. You need to use the Pentium kernel on these machines. >I can think of a lot of reasons why the i386 kernel was not >there - but maybe one would be that general RedHat support for Ultimately it was a disk space decision, as stated previously in the thread. The presence of an i386 kernel however would not be endorsement of "support" for i386/i486 processors. Our box, and documentation list the minimum system requirements for support. Any machines or hardware that do not meet the requirements, while unsupported, may or may not work, and may or may not have a kernel to use out of the box. >older hardware is not as good as MS (RedHat seems to sometimes >drop support for old hardware that was supported in the previous Try to install Windows XP on an i386 or i486 computer and see how far you get with Microsoft support. Anyway, I hope this clears up some confusion. Take care, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer XFree86 maintainer Red Hat Inc. -- Psyche-list mailing list Psyche-list@redhat.com https://listman.redhat.com/mailman/listinfo/psyche-list
