Re: Atlas-3.2.1
Camm Maguire wrote:
Hi Adam!
Adam C Powell IV <hazelsct@mit.edu> <mailto:hazelsct@mit.edu> writes:
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.
Right, I stand corrected.
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.
Cool, will do. Thanks very much!
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.
Really? Then what's the advantage of linking -llapack_atlas -lcblas etc.?
I'll switch the Build-Depends to atlas2-base-dev.
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.
So far, using Geomview, it has been a breeze. The next step,
distributed rendering, will take a lot of work though.
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?
I was under the impression that Kazushige Goto's alpha assembler BLAS
were included in ATLAS. If so, there are two versions: ev4-56 and ev6,
the former I think is optimized for ev5 but the latter does not run on
pre-ev6 CPUs since it uses things like hardware sqrt instructions. I
don't think the ev6-optimized version is that much faster except for
Cholesky decomposition which uses sqrt (dtrmm?).
Thank you again, these are terrific packages!
Zeen,
--
-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>
Reply to: