On Wed, Dec 21, 2011 at 09:05:49PM +0000, Martyn Foster wrote:
On 21 December 2011 18:14, Torsten Hoefler <[email protected]> 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