[Mpi-forum] Per communicator parameterisation

[Torsten Hoefler]

On Wed, Dec 21, 2011 at 09:05:49PM +0000, Martyn Foster wrote:
> On 21 December 2011 18:14, Torsten Hoefler <htor at illinois.edu> wrote:
> > You are correct and this is indeed a missing functionality in MPI-2.2.
> > There is a proposal that allows to attach info objects during
> > communicator duplication (see item #2 "MPI_COMM_DUP_INFO" in
> > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/271). This has been
> > discussed in the Forum but I don't know the status of this ticket. Adam,
> > can you comment?
> <snip>
> > Would this functionality suffice for your use-case?
> 
> Hi Torsten,
> 
> Yes, thanks. I think this is pretty much exactly what I was looking
> for. The only comments that I'd make on the ticket proposal would
> revolve around providing a method to do it in a single step (I suspect
> for several things a "comm_set_info" would be equivalent to recreating
> the communicator and no cheaper than the dup method). I can see the
> API problem, and I wouldn't want to see a huge explosion in interfaces
> - would it be better to be able to set the 'info' object to be used
> for subsequent communicator creation as well as the "creation and then
> modification" approach? e.g.
> 
> CALL MPI_Comm_set_default_info(My_Info_Sets(colour)) ! Set default
> info to be used based on my role.
> CALL MPI_Comm_split(Comm_In,colour,key,Comm_Out)
> CALL MPI_Comm_set_default_info(MPI_Info_Null) ! lets avoid accidental
> deadlock in future comm creation calls.
The problem with those things where you put state in the library is
always thread-safety. We just eliminated the last occurrence of
"library state" without explicit handles by introducing MPI_Mprobe and
friends. I imagine that the Forum would be opposed to re-introduce such
problems. 

We discussed this issue at depth and decided that the comm_dup approach
is most appropriate for a number of reasons. The best reasons are probably
(1) that it can be used with any communicator and (2) that it sets all
infos at creation time, i.e., the library can do special one-time
optimizations while the communicator is guaranteed to be "empty" (no
outstanding ops yet).

> It would also be nice to have a reserved set of info keys for the
> things that are common to most/many MPI/HW implementations- protocol
> thresholds etc, and a recommended namespacing for vendor specific
> stuff... but maybe the scope of that is too broad.
Yes, it would be, definitely, however, it is very tricky to define such
generic info keys. The Forum tried to add such infos wherever possible
but we are rather conservative (MPI lived 15 years so far and will live
much longer, and it is hard to predict future architectures), i.e., most
predefined info keys are only relative to the MPI interface, not to
specific hardware implementations.

You are most welcome to join our discussions and meetings! However,
version 3.technically in a feature-freeze right now and we move new
non-critical aspects to 3.1. 

All the Best,
  Torsten

-- 
 bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
Torsten Hoefler         | Performance Modeling and Simulation Lead
Blue Waters Directorate | University of Illinois (UIUC)
1205 W Clark Street     | Urbana, IL, 61801
NCSA Building           | +01 (217) 244-7736