Re: Fnal request for atlas package input
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(peter@llama.nslug. , 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
Reply to: