[Mpi3-subsetting] mpi3-subsetting Digest, Vol 2, Issue 3

[Richard Barrett]

> Also, lots of people seem to like the idea of getting rid of MPI_ANY_SOURCE
> in a subset.  I am one of these people.  MPI_ANY_SOURCE is a problem.  The
> difficulty is that the master in a master worker algorithm is likely to
> find MPI_ANY_SOURCE and MPI_PROBE useful.

This issue captures a (the?) key decision that this group must make imo. Is
the goal of the sub-setting to provide a performance boost, or to address
the "mpi is too big" concern? In some sense the concerns overlap, but here
is a big example of where they often don't.

Many of the applications I've worked with use it in setting up communication
(esp. in amr codes). And many of these people asked for an mpi-subset.
Interesting to note that for many of these codes, actual performance of the
send/recv is _not_ an issue - the work associated with preparing and
managing messages for those sorts of codes, as well as the work imbalances,
overwhelm the performance issues. (But note these code teams may _say_ mpi
performance is an issue, but a complete view of their communication
requirements does not support that claim.) However, they also require
MPI_ALL_REDUCE, and at the peta-scale, so performance there is critical.

MPI_ANY_SOURCE is found in many libraries I use, but library developers seem
to make significant use of mpi functionality, without complaint.

All this said, admittedly counter-claims and examples may be produced.
However, as Dick stated for the Master/worker model, a large segment of
users "require" MPI_ANY_SOURCE" somewhere in their code. I'm not saying a
decision needs to be reached quickly, but I do believe we should keep this
issue clearly in view in order to keep the discussions on-track.

Richard

-- 
  Richard Barrett
  Future Technologies Group, Computer Science and Mathematics Division, and
  Scientific Computing Group, National Center for Computational Science
  Oak Ridge National Laboratory
  http://ft.ornl.gov/~rbarrett