On Thu, Mar 01, 2001 at 11:02:35AM -0500, Camm Maguire wrote: > > Greetings! Well, the new atlas package is just about working as > follows: > > generic atlas-specific libs in /usr/lib > generic drop in replacement blas and lapack libs in /usr/lib/atlas > subarch-tuned atlas-specific libs in /usr/lib/<subarch> > subarch-tuned drop in replacement blas and lapack libs in > /usr/lib/<subarch>/atlas > dynamically linked testing binaries in /usr/lib/atlas > > For example, on i386, the generic arch is a Pentium Pro, and the two > subarchs at present are 3dnowext and xmm. (Might add p4 before > release.) > > These libs are *big*. The lib package now weighs in at about 11MB on > the i386. Upstream says there is little we can do to modularize the > subarch specific stuff. I might add a debconf option to remove > unwanted libs. Will need a warning about the math on the 3dnow > registers not being ieee compliant anyway. > > Of course, the other two options are: > 1) just install the generic, let the user rebuild if they like
I like that idea. There are enough different kinds of CPU cores and extensions that the number of permutations is way up there, esp. on x86. Having fully optimized code for each permutation would probably take too much space. For example, you have 3dnowext and xmm sub-archs, but really there is k6-2 3DNow!, k7 3DNow!, mmx, sse, sse2, and compiling with -march=k7, -march=pentiumpro, and others I think. (Maybe all these different permutations won't produce different binaries with the current implementations, but after further support for stuff is added things would get worse.) > 2) separate packages for 3dnow, sse, etc. > > Please let me know what you'd find most useful. I guess there's a tradeoff here between wasting space on the mirrors and on the user's disk, and saving the user time. For options that would give a big speedup, (i.e. more than 25%, as a good ballpark number), there should be packages for them, like an atlas-3dnow package. Something like 3DNow gives a big enough speedup to be worth making available easily. Small tuning options that give small speedups don't need separate packages of their own. However, make sure it's easy for the user to build from source to take the best advantage of the machine. If you provide an easy route for doing this, you don't have to worry too much about making different packages for different CPU features. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
