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

[Torsten Hoefler]

Jim,

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,
  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