[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