LAM/MPI logo

LAM/MPI General User's Mailing List Archives

  |   Home   |   Download   |   Documentation   |   FAQ   |   all just in this list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2003-07-03 20:19:47


On Thu, 3 Jul 2003 sutovas_at_[hidden] wrote:

> Version 7.0 seems to have great new features and I'm looking forward to
> start using it. The documentation (and the new http) is "pretty" and
> well organized. And now some questions:

Great -- hope it's helpful to you. :-)

> I know the Installation Guide specifically mentions that building the
> shared libraries will not work with the Portland Group compilers but
> does it work with the INTEL compilers?

We have tested with icc 7.0 IA32 and it seems to work.

> If I build both the static and dynamic libraries, how do I tell 'mpiCC'
> which one to use to link my application against?

This is more up to the local linker semantics than LAM/MPI. Most
compilers/linkers will tend to prefer the shared library if both are
present and you link with "-lfoo" (as the wrapper compilers do). You can
typically override this by foregoing the -L/-l syntax and instead listing
the specific file that you want to link to. For example:

        cc myapp.c ... /home/lam/lib/libmpi.a ...

would force the use of the static library if both were present. The
wrappers don't do this, though, so you'd have to be creative with -showme
to get the underlying list of libraries and then compile manually without
the wrappers. I don't recommend this.

It's typically easier to just install one or the other (IMHO).

> Suppose I built LAM (with shared libraries) at my site without the gm
> RPI module and I built my application with the LAM shared libraries at
> this site. Would I be able to use the gm module with my application at
> another site where LAM was built with the module?

I have not tested this. In theory, it should work -- if *everything* were
shared libraries (including gm). I would recommend against it, though --
a RedHat system is not exactly the same as a RedHat system, if you know
what I mean (i.e., one system may be patched and one may not, or one of a
million other changes that may result in binary incompatability). Since
MPI is source code portable, it's typically easier to just compile your
application at both sites (perhaps using CVS or some other source code
repository tool to keep your source code synchronized -- this is *exactly*
what we do with LAM/MPI development. Many people have been kind enough to
grant us guest accounts on their machines; I typically have a CVS checkout
on each of these machines).

> The User's Guide mentions that the supported number of tags is
> significantly increased in most RPIs. What is the new MPI_TAG_UB and
> which RPIs have the increased max tag?

The lamd RPI is the one that was holding the others back; it only has 12
bits available for the communicator ID mapping (i.e., 4096 total
communicators, including MPI_COMM_WORLD and MPI_COMM_SELF), and 15 bits
available for tags (32768 tags). 7.0 makes the max tag and CID values be
per-RPI, so the other RPI modules now allow 65536 communicators and
MAX_INT tags.

-- 
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/