[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New LAM package

>> Camm Maguire <camm@enhanced.com> writes:

 >    In the past, we had the 5 (static) libs shipped with lam
 >    installed under /usr/lib/lam/lib, and a "merge" lib built, with
 >    a link under /usr/lib, so that one could compile as simply as
 >    cc -I /usr/include/mpi *.c -o foo -lmpi.

 >    Now that the libraries are shared, all the lam stuff is loaded
 >    into memory when lamd is running.

 $ ldd /usr/bin/lamd 
         libargs.so.1 => /usr/lib/lam/lib/libargs.so.1 (0x40011000)
         libtstdio.so.1 => /usr/lib/lam/lib/libtstdio.so.1 (0x40017000)
         libtrillium.so.1 => /usr/lib/lam/lib/libtrillium.so.1 (0x4001f000)
         libt.so.1 => /usr/lib/lam/lib/libt.so.1 (0x40028000)
         libmpi.so.1 => /usr/lib/lam/lib/libmpi.so.1 (0x4003c000)
         libc.so.6 => /lib/libc.so.6 (0x40083000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

 so, after booting lam, each and every library is loaded.

 >    Linking to the merge library then loads in another copy when you
 >    run your program.

 "another copy"? which one is the merge library? From debian/rules, I
 guess it's liblam, but that isn't loaded by lamd...

 >    Sort of defeating part of the purpose for a shared library.
 >    (There is still a benefit when more than one mpi app is running,
 >    of course.)  Should I make all the lam1-runtime binaries link
 >    against the merge library, and eliminate the sub libraries, or
 >    should we eliminate the merge library, and force everyone to use
 >    hcc or a more complicated cc command line?

 Does it make a difference in terms of memory footprint for the
 utilities?  I've always used cc with -lmpi and the appropiate
 libraries, and normally don't use hcc (except when trying to explain
 some people here what to do to compile an MPI program)

 >    I haven't used the new mpicc with this package, but it may end
 >    up providing the implementation transparency (i.e. we want code
 >    to compile just as well with lam as with mpich)

 I've found some packages (CACTUS in particular) that use MPI, and
 IIRC, they do expect mpicc to be available.  At least in terms of
 compatibility with the rest of the MPI community, this is good.

 >    as we had achieved with the alternative and the merge library.
 >    Of course, combining the libs into one for all apps has clear
 >    advantages too, its just a (perhaps) significant change to the
 >    upstream package.

 MPI is lots more standard than, say, PVM.  I guess we should take a
 look at the MPI Standard, and try to preserve compatibility with
 that, which means, use mpicc, AFAIC recall.  I don't have the
 standard here with me.


Reply to: