[MPICH] semantic question re: groups
Rob Ross
rross at mcs.anl.gov
Wed Jul 27 09:50:26 CDT 2005
Hi David,
If the amount of data that you want to send in the reply is large, it
might be worth your time to first scatter a message from the master that
tells each slave if it needs to get the reply or not.
Creating the new communicator (if you want to) should be done with
comm_split; there's no need to create the intermediate group. If you
scattered an integer color in the first step, you could use that as the
input to the comm_split directly.
So that's a "neat" way to do it. However, unless the new communicator
is actually used for a decent amount of communication, you're probably
better off not creating it.
Another option would be to use a preliminary scatter to tell each slave
how much data will be sent, then use scatterv to send the data itself.
You don't have to create a new communicator, and no data is sent to
slaves that don't need anything in the second communication (scatterv).
If the amount of data is small, of fixed size, and you're going to send
to the majority of the slaves anyway, you might be best off to just
bcast it to all of them.
Some things to think about at least...
Regards,
Rob
David Minor wrote:
> Hello Newslist,
>
> I have a master process that gathers replies from all of its slave
> processes, then on the basis of the replies it needs to do a collective
>
> operation on a sub-set of the slave processes. What's the cleanest way
> to do this?
> I can create a group on the master process and then a communicator from
> the group, but the slave processes cannot create the same communicator
>
> without the duplicate global information that the master process holds.
> Each slave process only knows whether it is going to participate in the
> collective operation but it doesn't know anything about the other
> processes participating except the master process.
>
> I could do this of course with point-to-point operations, but it seems
> there should be a neater way. Any suggestions?
>
> David Minor
>
More information about the mpich-discuss
mailing list