[mpiwg-rma] MPI_WIN_CREATE for intercommunicators

maik peterson maikpeterson at googlemail.com
Wed Jan 22 03:14:52 CST 2014


thomas, today you should start thinking about other possibilities
to solve your problem. this mpi rma stuff is crappy.


2014/1/21 Thomas Jahns <jahns at dkrz.de>

> Hello,
>
> should this be the wrong mailing list[1], I apologize in advance and hope
> for
> directions to the correct place to pose my question.
>
> From the wording of the MPI 2.2 and 3.0 standards I can see (first
> paragraph of 11.2.1 in MPI 2.2, procedurce specification of
> MPI_WIN_CREATE in MPI 3.0) that MPI_WIN_CREATE is only allowed for
> intracommunicators.
>
> I was wondering why this restriction is there, when
>
> 1. cases where an intercommunicator is more clear for point-to-point
>    communications, communications using rma would equally gain in
>    clarity with an intercommunicator (from my POV at least),
>
> 2. the required resources (because the number of potential
>    communication paths would be much lower) could be reduced because
>    the intercommunicator not only specifies two groups communicating
>    with each other but also not communicating (at least via the
>    intercommunicator) within each group. I.e. when it is already known
>    that the any two processes within one of the two groups of an
>    intercommunicator would not issue RMA calls for the other,
>    corresponding resources need not be reserved. Intra-communicator RMA
>    on the other hand leaves the possibility of any communication pair
>    open.
>
>    Clearly with two groups of processes of sizes N and M the number of
>    potential pairs is N * M where a corresponding intercommunicator is
>    concerned but (N * M)**2 for an intracommunicator and
>
> 3. the semantics appropriate for an intercommunicator should be easy
>    to emulate with MPI_INTERCOMM_MERGE and MPI_GROUP_TRANSLATE_RANKS.
>
> Since allowing intercommunicators in MPI_WIN_CREATE would consequently
>
> 1. be aesthetically pleasing,
> 2. offer increased potential for efficient execution,
> 3. seem to have an easy proof-of-concept implementation strategy and
> 4. forms a pattern arising naturally from the rest of the standard in my
> eyes,
>
> I'm clearly missing some ambiguity or technical/definition difficulty
> here, but can't figure out which, why else would the standard
> explicitly restrict MPI_WIN_CREATE to intracommunicators if the above
> were the whole story?
>
> Kind regards,
> Thomas Jahns
>
> [1] I've done some searching and came up with either
> <mpiwg-rma at lists.mpi-forum.org> or <mpi-comment at lists.mpi-forum.org>
> --
> Thomas Jahns
> DKRZ GmbH, Department: Application software
>
> Deutsches Klimarechenzentrum
> Bundesstraße 45a
> D-20146 Hamburg
>
> Phone: +49-40-460094-151
> Fax: +49-40-460094-270
> Email: Thomas Jahns <jahns at dkrz.de>
>
>
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20140122/6be8f531/attachment-0001.html>


More information about the mpiwg-rma mailing list