[Mpi-forum] Per communicator parameterisation
Adam T. Moody
moody20 at llnl.gov
Wed Dec 21 13:38:38 CST 2011
Torsten Hoefler wrote:
>Dear Martyn,
>
>Thanks for bringing this up, the Forum appreciates any user input and
>comments. See my answers below.
>
>
>
>>Firstly, apologies if this is the wrong place to post - I couldn't see
>>a particularly relevant subgroup or forum for discussion, so if this
>>is the wrong place, redirection is more than welcome....
>>
>>
>The right place would probably be the collectives and topology working
>group, but I think the general forum list is ok as long as the thread
>does not grow too much.
>
>
>
>>[snip]
>>
>>As it stands there is no practical way of setting this up - even with
>>the generous support of my vendor. This is in stark contrast to MPI-IO
>>where I have data structures available to pass either vendor specific
>>or generic hints allowing me to modify behaviour on a per-file basis,
>>in application, at runtime. I really want to be able to perform a
>>similar thing when I create communicators, such that when I perform,
>>say, a comm_split, I can create unique characteristics for each of the
>>new communicators.
>>
>>
>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?
>
>
Hi Martyn,
Yes, the plan is to enable applications to apply info hints to
communicators at creation time. We didn't want to duplicate all of the
communicator creation calls, so instead we decided to add a single
MPI_COMM_DUP_INFO call that takes an info object and applies it to the
dup'd communication as it is created. To use this technique, you'd have
to create a temporary communicator through an existing creation call,
then create a copy of it with the info applied via COMM_DUP_INFO, and
finally free the temporary. Of course, you'd also need your MPI vendor
to provide relevant hints.
Except for some minor wording changes, this ticket was generally well
received by the forum, and the plan is to get it accepted with MPI 3.0.
-Adam
>
>
>>So I guess the first question is has any work been taking place in
>>this area, and if not, how do I go about spurring the discussion?
>>
>>
>Yes, Adam and I worked on this issue a while ago and Adam created the
>referenced ticket. Would this functionality suffice for your use-case?
>
>All the Best,
> Torsten
>
>
>
More information about the mpi-forum
mailing list