Re: Atlas-3.2.1
Hi Adam!
Adam C Powell IV <hazelsct@mit.edu> writes:
> Camm Maguire wrote:
>
> >Yep, you are right that this is the default behavior. To take
> >advantage of the Atlas structure, *packages* depending on the atlas
> >libs need the following in debian/shlibs.local
> >
> >libatlas 2 atlas2
> >liblapack_atlas 2 atlas2
> >libcblas 2 atlas2
> >libf77blas 2 atlas2
> >
> Right, but shlibs.local is (can be) automatically generated from the
> shlibs files of the shared lib packages themselves. For example, when I
OK, technically I think the shlibs.local is only used to override the
shlibs files from the currently installed packages, and is used most
commonly when a source package provides both shared library and
dependent binaries. The library is built in debian/tmp and has no
installed shlibs file, so shlibs.local is used to get dh_shlibdeps to
work on the binaries.
> build petscgraphics-demo which has a binary executable linking lots of
> shlibs, I don't specify any of the shlib dependencies in the binary
> package's Depends: field (they have to go in the Build-Depends:, but
> that's another matter). The dh_makeshlibdeps in the binary-arch target
> of debian/rules automatically uses ldd and other utilities to generate
> shlibs.local automatically. It then puts the result in
All this i right, except that shlibs.local is never made, rather the
shlibs files in /var/lib.dpkg.info are consulted.
> petscgraphics-demo.substvars, and is automagically included when
> ${shlibs:Depends} in debian/control is interpreted, putting the result
> in debian/petscgraphics-demo/DEBIAN/control. Right?
>
> So, if I build petscgraphics with atlas2-p3-dev installed, it links to
> soname /usr/lib/xmm/libatlas.so.2 and friends which are provided by
> atlas2-p3, and /var/lib/dpkg/info/atlas2-p3.shlibs is consulted, which
> says libatlas 2 is provided by atlas2-p3. So that is put in the
> dependency, and petscgraphics-demo will depend on atlas2-p3. This is a
> big problem for everybody without a p3.
>
> However, if you change atlas2-p3 to atlas2 in your atlas2-p3.shlibs
> file, then petscgraphics-demo will depend on atlas2, and the user can
> have any flavor installed which provides atlas2.
>
You know, I thought this was against policy, but I just reread, and it
doesn't seem so. And certainly makes things easier for people
depending on atlas. So I just implemented in -9, which should be
uploaded sometime tomorrow :-)! Please check it out.
> Makes sense now?
>
> Note that a feature of this automatic shlib dependency generation is
> that on arches which need lapack instead of atlas, the lapack2 (or
> whatever) dependency is automatically generated, so I don't need to
> customize this section of the petscgraphics package. In fact, because
> it just Build-Depends on petscgraphics2.1.0-dev (it doesn't directly
> link anything else), which Depends on the appropriate local linear
> algebra implementation (lapack-dev, atlas-dev, or even cxml on alpha
> systems where PETSc is built using the Compaq compilers and libs), the
> linear algebra dependencies are automatically dragged in from PETSc
> without having to think about them at all in petscgraphics! And the
> less I have to think about, the happier I am.
>
> >As for portability, what I do is to Build-Depends: atlas-dev [!powerpc],
> >lapack-dev [powerpc]. Hmm, maybe atlas-dev | lapack-dev would be better?
> >
> >
> >What you have above will certainly work (outside of the fact that
> >atlas-dev doesn't exist anymore...). But if you have shlibs.local as
> >above, and dynamically link, then you can just Build-depend on
> >lapack-dev, which I think should be available everywhere, and your
> >users can still get the speedup by installing atlas. Your choice.
> >
> I don't think so. If I Build-Depend on lapack-dev, then packages will
> be built with -llapack and -lblas, but without -latlas, -lcblas, etc.,
> so installing atlas won't do anything to speed up the resulting binaries.
>
O contraire (sp?)! That's the beauty of this, IMHO. You *can* link
just with -lblas and -llapack, and installing atlas will provide
optimized versions of those libs, speeding things up without a
recompile. And, as earlier indicated, these may be available for more
platforms given atlas' size. Ocate, and I believe R, are already in
the process of using this feature. Check the file-list of the atlas
packages.
> atlas-dev may not exist any more, but it's the only common Provides:
> among your atlas2-*-dev packages, so I changed atlas2-dev to atlas-dev.
> If your packages provide atlas2-dev, then I'll change it back, so
> nobody tries to build PETSc against ancient atlases. :-)
>
> Then again, would building against ancient atlases be a problem?
>
Please check the sid versions -- atlas-dev is gone, i.e. not provided.
No problem, I'd think, with compiling against old versions. But you
might want to consider atlas2-base-dev for the newer versions for
build-depends, if, as I think we agree below, a virtual -dev package
is not warranted. I.e. something like atlas-dev | atlas2-base-dev, if
you want.
> >>>I thought about a virtual development package atlas2-dev, but then
> >>>only one of these could be installed at a time, as someone would need
> >>>to own /usr/lib/libatlas.{so,a}, even if a link, for it to be
> >>>transparent.
> >>>
> >>Hmm, why can't they all just provide atlas2-dev? I think I'm missing
> >>something. As long as the user sets LIBRARY_PATH appropriately at
> >>compile time, it should "just work", right?
> >>
> >
> >Well, I don't know if this is policy or anything, but I thought that
> >the idea behind a virtual package is that everything should work
> >unchanged if any one of the providers is installed. So in this case,
> >this is not transparent as the user would have to set LIBRARY_PATH or
> >-L on link command line depending on which -dev was installed. It
> >will work, but not transparently. Does this merit a virtual package?
> >
> See above; it's your call, but if the new atlas packages are not
> source-compatible with the old ones (pre-atlas2-dev), then I think it
> would merit a new virtual package.
>
They are source compatible, to my knowledge. But the current strategy
is not not have a virtual-dev package. Build-depends should be on
atlas2-base-dev, blas1-dev, or lapack-dev.
> >OK. Thanks for your work on Debian! BTW, what are you developing
> >that depends on atlas?
> >
> Lots of PDE stuff, centered around finite difference, finite element and
> boundary element (which gains a LOT from atlas because of the dense
> matrices), and some graphics, pretty much all PETSc-based. (I'm not
> sure the graphics will use atlas, depends on how low-level we have to
> program that part for good speed.) So most of this is an issue for our
> group based on the PETSc dependencies.
>
Neat. Wish I knew graphics.
> With regard to PPC, yes, I'm a PPC user, but not Altivec (yet?), just a
> 160 MHz 603e I've used as my home machine since getting it for $500
> three years ago. I think the really big Altivec gains come in
> single-precision, where it gets 2 Flops/clock sustained- as good as
> alpha! But unlike alpha, for double-precision, it doesn't have the
> bandwidth for that, even to cache. (I'm not positive about that, any
> other PPC folk here?) If it did, I'd probably make a Beowulf out of
> G4s, maybe even Cubes from ebay since they're low-power and fanless. :-)
I don't even know if the Altivec vectorizes double precision. Anyone
care to comment?
>
> So I think G4 users would appreciate an altivec-optimized atlas. And us
> alpha users would appreciate ev5 and ev6 versions too... as your time
> permits. :-)
In general, I was planning on building special versions only in the
case that cpu extensions were used, i.e. meaning that a given lib
would not run at all on certain machines of the arch. For the libs
whichi use the common generic arch supported code, my hope was to use
the build on the fastest reasonable representative for the standard,
as most people wanting to use atlas would have this type of hardware
anyway. Don't know where ev5/6 falls here. Can all ev6 code run on
the ev5? Does anyone know why lully and faure are perpetually
inaccessible these days?
Take care,
>
> Thanks again,
> --
>
> -Adam P.
>
> GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
>
> Welcome to the best software in the world today cafe!
> <http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian-beowulf-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: