On Mon, 2002-10-14 at 22:01, Thomas Dodd wrote: > > > Jean Francois Martinez wrote: > > On Mon, 2002-10-14 at 18:25, Florin Andrei wrote: > > > >>What is the reason why there are kernel RPMs optimised for Athlon, but > >>no glibc RPMs for Athlon? > > > > > > Perhaps there isn't much to be gained. AMD knows far too well that > > because it is the "minor company" most of the time its processors will > > be running code who has been optimized for Intel processors. So if > > AMD wants to stay in business it would be better if its processors > > are relatively insensitive to code who is not specifically targetted > > for them: for instance it could be there are only 1 or two percent > > slower when crunching code for 686. > > AMD has different instructions that perform well. Not sure if it's > still true, but at one time AMD had some instructions that were much > faster than the *ntel versions. The *ntel optimization guide said not > to use them, but they were fine on the AMDs, often faster than the > *ntel recommended way. > There are two different phases when optimizing for a processor: first taking account the different speed table and pipelining: for instance copying memory on 386 and 686 is faster by using a special instruction while in the 486 and Pentium it is faster by using a loop who loads a register and unloads it at destination. The second phase is using non-386 instructions. Benchmarking shows that with all versions of gcc the first phase brings the lion share of the speed improvement: ie if you will be running on a 686 then the use of -mcpu=i686 (account for 686 speed table but use only 386 instructions) brings over 10% improvement over -mcpu=i386 but using -march=i686 (use different speed table AND 686 instructions) only brings around a 2% speedup. This could be change when gcc will be good with mmx-like instructions but the limited tests I have been able to do point that for now gcc does a poor job with MMX and friends (my _limited_ tests point to zero benefit), Now it doesn't matter if the limited effect of special instructions is inherent or due to gcc. Since RedHat has to use gcc it is gcc performance who will make for if they need to bother with RPMs made specially for the Athlon or if it brings epsilonian improvements. Also since not all back ends are of equal quality at times "optimizing" for the processor brings a slowdown: the K6 will run faster on code who is compiled with -mcpu=i686 than with -march=k6 and that is valid both for gcc 2.96 and 3.2. > But how often those instructions can be used may be limited. If > they aren't often used it's not worth the effort to change them. > > > The glibc on the other hand has only a handful routines who are written > > in assembler and for the gain obtained from gcc parms I would tell it is > > probably quite small judging from what you get with other processors. > > Every thing is machine code. While glibc may not have many hand coded > sections, the compiler still creates asembly code. Telling the compiler > to generate code for a given CPU can help. Often its not worth the > effort though. When I told assembler I meant hand written assembler. As I said with present gcc you can get some speed improvements by tuning to the CPU but while measurable they are not earth shattering even when you compare to code optimized for a true Pentium (who is a worth case on everything who is not a TRUE Pentium, not even Pentium MMX) > > >>Which is the reccomended glibc package to install on an Athlon system? > >>The i386 or the i686? > > Use the i686 version on the Athlon. > Benchmark first and draw conclusions later: for instance you could assume that code optimized for Pentium will run faster than code for 386 when CPU is a 686. Wrong. Of course there there are good marker reasons for AMD trying to have a timetable close to the one used by contemporary Intels. That could mean a PIII-like table for first Athlons and a PIV-like (completely different) on the Athlon-XP > > I would be glad to benchmark them alongside with a glibc purposefully > > built for the athlon provided you send me one. :-) > > > > Seriously, run a couple benchmarks on both plus use the SRPM to rebuild > > an athlon optimized glibc (rpm -ba --target athlon glibc.spec), > > benchmark, compare and publish the results. > > The bench/compare would be nice. But what do you use to benchmark glibc? > Take something CPU intensive (eg bzip2 -c file >/dev/null) and use LD_LIBRARY_PATH. Let cool the processor between runs: a hot processor is slower. > Also, it probably would take more than just a --target change. > You need to make sure the correct flags are passed to the comliler, > and indifferent sections of the code you may need different flags. > In case you haven't looked changing --target will have as effect that gcc will use different flags. For -D parms that RedHat should know but you could look at the assembly files (not so many) and modify the spec file if needed > Start by looking at the specfile, and what flags it uses for i686 > and i386. Then look at where they get used in the glibc build process. > Then you start trying different flags for Athlon. Some flags might > break the build, or cause problem at runtime. > > -Thomas > > > > _______________________________________________ > Redhat-devel-list mailing list > Redhat-devel-list@redhat.com > https://listman.redhat.com/mailman/listinfo/redhat-devel-list > _______________________________________________ Redhat-devel-list mailing list Redhat-devel-list@redhat.com https://listman.redhat.com/mailman/listinfo/redhat-devel-list
