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. 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. >>Which is the reccomended glibc package to install on an Athlon system? >>The i386 or the i686? Use the i686 version on the Athlon. > 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? 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. 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
