[mpi3-coll] [MPI Forum] Ticket #168 MPI_Icomm_dup

Torsten Hoefler htor at illinois.edu
Tue Nov 22 16:42:01 CST 2011


We talked about it and you agreed after a short explanation. Let me
summarize our discussion for the others here.

> I have a couple questions about this proposal:
> Why MPI_Icomm_dup() and not MPI_Icomm_create()?  It seems like  
> MPI_Icomm_create would be more general while still providing the same  
> capability.
Comm_create is a generalization of comm_dup and may thus be a more
general solution. However, the only use-case that we know is for
libraries (comm_dup) and comm_dup provides due to it's limited semantics
an easier and potentially better-performing solution.

> Why is this crucial for nonblocking libraries?  It seems like a  
> synchronous initialization routine for such a library should be  
> sufficient from a functionality point of view.  Is this primarily a  
> performance argument?  Maybe you can point me to a specific passage in  
> the paper?
It's in Section 3.3 in http://www.unixer.de/publications/index.php?pub=135 .

A synchronous initialization would be necessary for *each* communicator
*and* needs to propagate upwards in stacked libraries (forcing
synchronous initialization of all levels in the call-stack above).  This
does not compose and can easily create a mess.

All the Best,

 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

More information about the mpiwg-coll mailing list