On Mon, 21 Oct 2002, Thomas Dodd wrote: >> 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. > >Except a i586 kerenl is horrribly slow on a K6. I've never done an in depth comparison, but I wouldn't consider it to be all that bad. The K6 should reorder things internally I would presume anyway to be more optimal. Have you done any benchmarking? I used to use home brew K6 kernels, but then switched to stock kernels not long after starting at Red Hat. QA testing became more important to me. ;o) >> This combination gives the biggest bang for the buck, while >> maintaining a high level of compatibility. > >So the packages are buildt with -march=i386 -mcpu=i686 right? Correct. >So owners of a true Pentium would probably benifit from >a -mcpu=i586 version of glibc. That is also probably quite correct. >> 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. > >Another reason to supply a i386 kernel. Why? The CMOV instruction is an i686 instruction, not an i586 one. The i586 kernel thus does not use CMOV, and so i586 kernel should work on Cyrix. >My understanding is that the i586 scheduler (compiler) creates >code that only runs well on an actuall *ntel Pentium. Not a K5, >K6, or Cyrix. Not a i686 (PPRo, PII, or PIII), not a Pentium w/ >MMX. That is a reasonable assumption. Note however that newer CPU's internally reorder instruction execution to be more optimal at runtime. There is no question at all, that providing a kernel customized for every single CPU brand/model would be most optimal for that particular CPU brand/model. That isn't however remotely reasonable from an engineering and support perspective. We could technically supply 30 kernels in the distro, each one optimized for a particular CPU. It would take an incredible amount of time for the kernel builds to finish, and we would be faced with a tech support nightmare. I can totally respect anyone wanting to rebuild the kernel or some application, or library for the best performance for their own system. However, we are producing a general purpose operating system distribution, and we need to minimize the amount of per-system customized packages that we ship and support in order to have engineering and support sanity. The more we ship customized for different systems, the more we divide our engineering and QA resources, as well as other resources. >So offering a i586 optimized kernel, to all the i586 compatible CPU >that cannot use the i686 instructuions slow them down, yet there >are more CPUs that perform bably with that code that there are that >it helps. A i386 optimized sheduling is faster on most CPUs than >Pentium optimized code. So rebuild the kernel customized for your CPU. What we provide in our stock distribution covers the largest number of users, with the most popular hardware, and gives reasonable performance or better. Most operating systems come with one kernel period, and you use that kernel regardless of what CPU you have. You have no choice whatsoever. With Linux, you do have a choice. You can use one of the kernels that we provide, and offer support for that is optimized for your specific CPU type, or you can use the kernel which we ship that most closely matches your CPU, or you can use the kernel source code, and recompile an unsupported kernel, which is optimized for your specific CPU. There are lots of choices. We just can't possibly support the matrix of 100 possibilities that can exist out of the box, and so we don't. I use the i586 kernel on a K6, and a K6-3 machine, and it works perfectly fine. A kernel built specifically for K6 would likely perform better in some areas, but I seriously doubt there is any majorly noticeable difference. Most people do not ever actually benchmark things to see the real differences, and just hold to the placebo effect of bigger number == better. IMHO, if someone really cares that deeply to have a kernel optimized for their particular CPU, model, make, and stepping, the source code is available for free.... go nuts. >keep changing the CPU selection form Pentium to K6, in the i586 >kernel config file an rebuilding the kernel on my Athlon where >it build reasonably fast. That's fine. If you believe you get performance gains, by all means rebuild the kernel if it makes a noticeable differnence and you do not require official Red Hat support. Keep the provided kernel around, for if you experience a problem and can duplicate it on an official kernel and you're good to go. Just don't expect to see a k6 built kernel on the CDROM set soon. ;o) An athlon glibc would be nice to test. Not sure if it would provide noticeable difference or not as I'm not sure if gcc takes advantage of anything new in the athlon instruction set or not. Athlon optimized string operations would be nice, but I don't think gcc takes advantage of anything that useful on athlon yet. It'd be very cool though to have if one of the compiler guys could provide info about gcc's athlon optimizations, and if someone would implement useful tidbits if it hasn't been done already. If anyone experiments with a glibc rebuild, be sure to do some before and after benchmarking with useful tests and post back to the list. I'd give it a crack myself, but I don't have an Athlon handy to muck around with. ;o/ 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
