<html><body>
<p>One argument for subsetting is that MPI is somehow not well suited to massive master-worker applications. It does seem reasonable to me that pure master-worker applications have little use for many of MPI's features. Most communication may be point to point because workers are not expected to cooperate or communicate among themselves. Groups, topologies, new communicators, MPI-IO etc are not very useful.<br>
<br>
In the simple case, the master hands each worker a piece of work to do and the worker runs on its own until the work is done. As a worker finishes, it sends an answer to the master and waits to be handed another piece of work. Some pieces of work are brief and some are not so workers are not synched with each other and the master does not know who will have an answer next.<br>
<br>
My impression is that the biggest problem with MPI for this model is that with one master and many workers, it is not hard to make an application that can survive the loss of one or more workers. The master just hands out the lost work assignment again. MPI is not an ideal fit because the loss of one member of MPI_COMM_WORLD will probably bring down the job. A simple subset will not resolve this. An Fault Tolerant subset could be considered if this is an important rationale for a subset.<br>
<br>
Also, lots of people seem to like the idea of getting rid of MPI_ANY_SOURCE in a subset. I am one of these people. MPI_ANY_SOURCE is a problem. The difficulty is that the master in a master worker algorithm is likely to find MPI_ANY_SOURCE and MPI_PROBE useful.<br>
<br>
Dick <br>
<br>
Dick Treumann - MPI Team/TCEM <br>
IBM Systems & Technology Group<br>
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
</body></html>