-
Notifications
You must be signed in to change notification settings - Fork 2
MPI endpoints
On 16 Oct 2015, at 20:19, Steven Oyanagi [email protected] wrote:
Hi,
A few other items we might want to talk about:
- There were issues with MPI_GROUP and COMM_COMPARE for endpoints (see Dan’s resend back on 8/10). Did those issues ever get resolved?
- There was discussion when Pavan (and Jim) were not present about defining MPI process better. Is that still an open issue for discussion?
- There is also Dan’s Outstanding issues with endpoints document from May (see the last entry in the endpoints ticket). Are those issues resolved?
Sorry if these items have been resolved. I missed a few telecoms and the last face-to-face Forum in Europe. For all I know Jim is addressing all of these issues in the next endpoints update.
- Steve
On 27 Feb 2015, at 23:25, Jim Dinan [email protected] wrote:
Hi Dan,
Thanks for doing such a nice job of capturing the new text for group/comm compare. I updated the draft proposal with the new text and uploaded it to the ticket at https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/380.
I agree on the inadequacy of the interface comments. I think the question we should raise first is whether we need to solve this problem as part of endpoints, or whether what we have is sufficient and this problem should be addressed separately.
Cheers, ~Jim.
On Thu, Jan 29, 2015 at 1:22 PM, Daniel Holmes [email protected] wrote: Hi Jim/all,
I won't be able to attend the next Hybrid WG teleconference (I'm on holiday from tomorrow until 10th Feb) but that will be the last opportunity to discuss changes to the endpoints text before it needs to be sent to the forum mailing list if it is to be in time to be formally read.
At the last teleconference, we decided that we should look at a "minimum change" option and a "maximum readability" or "maximum de-duplication" option.
--- exec summary ---
This is a tricky change with unexpected repercussions to other areas that needs a lot of careful thought. It would be unfortunate if that extended effort delayed/derailed the main endpoints proposal. We have a very good reason to go for the minimum change option described below.
--- option 1 - minimum change ---
I think that the obvious "minimum change" option is that we propose not to change MPI_COMM_COMPARE or MPI_GROUP_COMPARE at all and not add the new result of MPI_ALIASED either. This could be moved to a separate proposal that would be dependent on #380 passing. Some would claim the new comparison ticket would be essential if endpoints passes - this is the only good reason to combine the two changes.
--- option 2 - maximum readability/de-duplication ---
This is the current text for MPI_GROUP_COMPARE:
MPI_IDENT results if the group members and group order is exactly the same in both groups. This happens for instance if group1 and group2 are the same handle. MPI_SIMILAR results if the group members are the same but the order is different. MPI_UNEQUAL results otherwise.
Here's suggested new text for MPI_GROUP_COMPARE:
Groups are identical if they contain the same group members in the same order. Groups are similar if they contain the same group members but not in the same order. MPI_IDENT results if the group handles refer to the same group member in identical groups. MPI_ALIASED results if the group handles refer to different group members in identical groups. MPI_SIMILAR results if the group handles refer to the same group member in similar groups. MPI_UNEQUAL results otherwise.
This is the current text for MPI_COMM_COMPARE:
MPI_IDENT results if and only if comm1 and comm2 are handles for the same object (identical groups and same contexts). MPI_CONGRUENT results if the underlying groups are identical in constituents and rank order; these communicators differ only by context. MPI_SIMILAR results if the group members of both communicators are the same but the rank order differs. MPI_UNEQUAL results otherwise.
Here's suggested new text for MPI_COMM_COMPARE:
Communicators are identical if they have identical communication contexts; this implies that their underlying groups are also identical. MPI_IDENT results if the communicator handles refer to the same rank in identical communicators. MPI_ALIASED results if the communicator handles refer to different ranks in identical communicators. MPI_CONGRUENT results if the two communicators have identical underlying groups but different communication contexts. MPI_SIMILAR results if the two communicators have similar underlying groups. MPI_UNEQUAL results otherwise.
--- notes ---
Talking about same|different group members in identical|similar groups is preferred over talking about same|different ranks because "same|different rank in similar groups" does not guarantee "same|different endpoint in similar groups" which is what we want to say without including the word "endpoint".
Talking about ranks in communicators is preferred over group members because communicators do not have group members even though their underlying groups do. They perhaps have members, i.e. without the "group" qualifier.
The phrases "same rank" and "different ranks" are only ever applied to identical communicators because they are only guaranteed to mean "same endpoint" and "different endpoint" for identical communicators.
--- issues ---
This range of responses is incomplete and therefore inadequate. Incomplete because, for example in the group comparison: MPI_SIMILAR_ALIASED results if the group handles refer to different group members in similar groups.
Inadequate because it seems that the interesting definition for the "aliased" property of handles is whether or not they refer to the same endpoint or different endpoints. To be able to determinable that for any two group/comm handles, "aliased" must be completely orthogonal to all the other criteria. We would need an additional MPI_UNEQUAL_ALIASED response for both comparison functions as well as MPI_CONGRUENT_ALIASED for communicator comparison. This implies that MPI_GROUP_ALIASED(group1, group2) and MPI_COMM_ALIASED(comm1, comm2) is a better approach.
One of the main reasons for needing to know whether or not two handles refer to the same endpoint is the proposed restriction on usage of group manipulation functions, i.e. not allowing aliased handles. I believe we should define a fix for each of these functions so that this restriction is not needed.
--- conclusion ---
This is a tricky change with unexpected repercussions to other areas that needs a lot of careful thought. It would be unfortunate if that extended effort delayed/derailed the main endpoints proposal. We have a very good reason to go for the minimum change option.
Cheers, Dan.
On 9 Jun 2016, at 00:05, Steven Oyanagi [email protected] wrote:
Hi,
Please see the branch fix_hybrid-process-clarification which should be a branch off of hybrid-process-clarification that can be fast-forward merged on to the hybrid-process-clarification branch. I fixed my 100 pages, Jeff Hammond’s commit, and part of Dan Holems’ commit. Dan’s commit affected two files, but oddly the second of the two files was already fixed for “MPI” -> “\MPI/“.
Note also that I do not have the capability at this time to convert the Tex source into a final document (not installed on my macbook) so there might be some issues in this branch and my original commit that a format would uncover.
Let me know if anything else needs to be done.
- Steve
Needs to be distinguished, e.g. endpoints don't call init or finalize.
Doesn't work because attribute deletion callbacks can invoke blocking collectives.
Hi Dan,
I don't recall if we considered this option when discussing a query function. But, in case this didn't come up, I created a ticket for it.
~Jim.
---------- Forwarded message ----------
From: MPI Forum [email protected]
Date: Tue, Sep 22, 2015 at 11:59 AM
Subject: [MPI Forum] #485: MPI_COMM_TYPE_ADDRESS_SPACE
#485: MPI_COMM_TYPE_ADDRESS_SPACE
This ticket proposes a new communicator split type, MPI_COMM_TYPE_ADDRESS_SPACE. The result of this split will be a new communicator containing all processes in the parent communicator that share an address space with the calling process.
Processes may share an address space when processes are implemented as threads, or when the proposed MPI endpoints extension is used. Compatible applications and libraries could use this query to optimize for shared memory. For applications or libraries that rely on processes occupying separate VA space (e.g. they rely on per-process global or static data) this query would allow these codes to detect whether they are compatible with the given communicator.
INFO hints or extend definitions of thread support levels.