Re: New LAM package
Hi Marcelo!
"Marcelo E. Magallon" <mmagallo@efis.ucr.ac.cr> writes:
> >> Camm Maguire <camm@enhanced.com> writes:
>
> $ 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...
>
If you do a ldd on an app you compiled with cc -lmpi, you'll see its
linked against liblam, the "merge" library. Thus when your app is
running, and lamd is running, effectively two copies of the code are
in memory, I think.
> > 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 guess my thought was that lamd is basically *always* running on an
mpi system, and so none of the utils which only link against some of
the libs will increase their effective footprint, as lamd has made
sure all are in memory anyway.
Actually, there may be some small memory savings with the merge:
intech19:/usr/lib/lam/lib$ ls -l *.1.0 | grep -v liblam | awk '{x+=$5} END {print x}'
409816
intech19:/usr/lib/lam/lib$ ls -l *.1.0 | grep liblam | awk '{x+=$5} END {print x}'
388160
> > 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.
>
Good idea. Agreed, mpicc should work no matter what. I think it can
work with or without the merge. But at least I know one other person
found cc -lmpi useful! Ideally, we could have both functionalities.
I've just fired off a note to the LAM maintainers asking them if they
would have any objection to replacing the sub-libs with the merge.
We'll see what they say.
>
> Marcelo
Thanks so much for your feedback!
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: