Re: Fnal request for atlas package input
Greetings!
Drake Diedrich <Drake.Diedrich@anu.edu.au> writes:
> On Thu, Mar 01, 2001 at 11:02:35AM -0500, Camm Maguire wrote:
> >
> > 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.)
>
> Just wanted to verify that this means the generic package runs on any
> i386, but is tuned for Pentium Pro.
>
Yep!
> >
> > 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
>
> I don't think I like packages that are self modifying outside the
> packaging system. I'd rather either have it in one big lump or several
> smaller packages.
>
OK, I think I agree. What do you think of having one package which
covers major subarch divisions, or a package providing only the
generic, and allowing the user to rebuild and tune to their hardware?
The latter is certainly simpler, but
1) It assumes some ability on the users part to handle the versioning
of the custom packages, so that their package isn't automatically
'upgraded' to the generic
2) Can't share /usr across different subarchs (does anyone do this
anyway?)
3) Have to remember to rebuild when upgrading CPU, or moving system
disk into a different machine.
Maybe these issues aren't really that important, after all. There was
originally some preference expressed on debian-beowulf for this
functionality, but the balance seems to have shifted.
> > registers not being ieee compliant anyway.
>
> Oh. Ick. I didn't know this. Have to think real hard about the next
> purchase. May be the straw that pushes us to an SMP Intel cluster instead
> of Athlon or Duron. :(
>
Yep! Double precision on the Alpha is *great*, though. Still, a P4
with SSE2 looks like it beats the alpha in $/flop. 3dnow has no inf,
nan, etc.
> >
> > Please let me know what you'd find most useful.
> >
>
> Are you (or Atlas) aware of the PPC Altivec matrix libraries that Paul
> Mackerras has been working on? Might be worth integrating in the future.
> He's claiming 2 Gflops real (not theoretical) on matrix-matrix multiplies on
> a Mac G4 cube. A quick web search didn't turn anything up on this, so it
> may still be unpublished, but forewarned is forearmed. You may be dealing
> with subarches on platforms besides i386 soon. :)
>
Thanks for the info! I'll forward upstream. Atlas does run on the
ppc, to my knowledge, but I don't know about subarchs there.
> > PS. What about using the alternative system to allow user switching
> > from blas/lapack to atlas versions?
>
> I don't think most users would care (they'd just install the fastest and
> be done), but for developers and reviewers this would be useful,
> especially if you add an LD_PRELOAD script for each to make testing the
> different BLAS easy without reinstalling or relinking.
>
Good to hear you like the LD_PRELOAD idea. That's what we have with
the current atlas. Drop in run-time library switching for blas and
lapack via LD_LIBRARY_PATH=/usr/lib/atlas.
Take care,
> For instance, under IRIX to switch to using locally compiled
> software-only mesa libs in place of the system GL libs:
>
> #!/bin/sh
>
> export _RLD_LIST _RLD64_LIST _RLDN32_LIST
> _RLD_LIST=/usr/lib/libm.so:/usr/local/Mesa/lib/libGL.so:DEFAULT
> _RLD64_LIST=/usr/lib64/libm.so:/usr/local/Mesa/lib64/libGL.so:DEFAULT
> _RLDN32_LIST=/usr/lib32/libm.so:/usr/local/Mesa/lib32/libGL.so:DEFAULT
>
> exec $*
>
>
> The equivalent linux script uses LD_PRELOAD or LD_LIBRARY_PATH (in man
> ld.so).
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: