On Tue, 22 Oct 2002, Thomas Dodd wrote: >> 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 > >Not sure there. The instruction mix from the compiler should >be different, causing problems for the schedulers. Yes there would likely be some amount of that. >> 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) > >No idea what to bench with. The whole problkem with benckmarking >is timing the right things and figuring out what it means :) Indeed. >>>So owners of a true Pentium would probably benifit from >>>a -mcpu=i586 version of glibc. > >Since it would give a more optimum instruction mix. Yep. >> That is a reasonable assumption. Note however that newer CPU's >> internally reorder instruction execution to be more optimal at >> runtime. > >When the PII and K6-2 came out, I remember the optimization >guide saying that the new CPUs ran i386 optimized code faster >than pentium optimized code, and to not use the pentium >guidelines anymore. I'm not sure in todays day and age of Athlon XP and Pentium IV, just how much it really matters though. >> 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 > >Didn't mean that ;) > >But if most pre i686 CPUS (pre PPro/PII/Athlon) run the i386 code >mix faster than the pentium mix, why not supply the i386 mix. >I woul thing there are more 486s, P/MMX, K5, K6, and Cyrix CPUs >still in use than Pentiums (pre MMX). There is no mechanism available to measure the exact number of each make/model of CPU that is in current usage. You are only guessing that there are more 486's et al., than Pentiums. I disagree completely, however neither of us has actual factual statistical data to indicate what the true reality is of CPU's in current usage. Without any factual statistical data, it is rather pointless to change the existing defaults based purely upon conjecture. It'd IMHO be easier to circumvent the whole "problem" per se, and just ship i686 and athlon kernels and not support any non-i686 or higher class hardware. That'd be my own personal vote for a solution to the "too many kernels" problem. ;o) I'd cut off several of my own machines doing so... but i know how to compile a kernel fairly easily enough.... >> 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/ > >I'd do it, but I havent a clue how to build glibc that way, or >how to test the results. rpmbuild -bb --target=athlon glibc.spec Watch what compiler options get used when you do that to ensure they are what is expected. If not, then also set RPM_OPT_FLAGS. -- 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
