Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] MPI_Comm_split
From: Hicham Mouline (hicham_at_[hidden])
Date: 2010-11-24 16:55:58


> -----Original Message-----
> From: users-bounces_at_[hidden] [mailto:users-bounces_at_[hidden]] On
> Behalf Of Bill Rankin
> Sent: 24 November 2010 15:54
> To: Open MPI Users
> Subject: Re: [OMPI users] MPI_Comm_split
>
> In this case, creating all those communicators really doesn't buy you
> anything since you aren't using any collective operations across all
> the subgroups you would be creating.
>
> For this sort of course-grained parallelism, your best bet is probably
> a master/slave (producer/consumer, worker-pool) model. Have one
> process (master) generate valid sets for your first X (of Y total)
> parameters. The master then sends a unique set of these parameters to
> each slave process. Each slave generates all possible sets of the
> remaining parameters, evaluates the function for those parameter sets,
> stores the local max/min and returns this value to the master. Upon
> receiving the max/min from the slave, the master compares this to the
> global max/min and sends the slave a new set of the first X parameters.
> Repeat until the master has sent all possible sets of X parameters and
> all slaves have processed all their work.
>
> Looking at it as a tree, the master process traverses the top of the
> tree, handing each slave a branch and letting the slave traverse the
> remainder of the tree. For load balancing, you want a lot more
> branches than you want slaves so that each slave is always kept busy.
> But you also want enough work for each slave to where they are not
> constantly communicating with the master asking for the next set of
> parameters. This is done by adjusting the depth to which the master
> process traverses the parameter tree.
>
> Hope this helps. Good luck.
>
> -b
>
It does very much, thanks a lot.

The tree is not symmetrical in that the valid values for the 10th parameter
depends on the values selected in the 0th to 9th parameter (all the ancestry
in the tree), for e.g., we may have a lot of nodes in the left of the tree
than in the right, see attachment ( I hope they're allowed )

The depth of the tree of course is the same everywhere, but not all nodes at
some level have the same number of children.
Is it better to just list vertically all the possible branches (n-tuples) at
the master level and split that list uniformly over the slaves?

regards,



tree-param-sweep.JPG