>
> My main comment is this: there are plenty of functions to start *more*
> MPI processes given one, and connect up any number of existing MPI
> processes; now all that's missing is a standard function to start
> *one* MPI process, given none. In other words, a function to make a
> random process into a singleton MPI application (with its own
> COMM_WORLD, rank=0, MPI_Comm_size=1).
>
> With such a function we could dispense with mpirun and friends
> altogether, and any application could just use this function to
> "become" the first process, and then spawn all the rest of the
> processes.
I think we don't want to encourage people to spawn one process
and have it spawn the rest, unless there is some
fundamental reason their application needs to do this).
The reasons are:
0. MPI-1 has already established the standard "look and feel" of
an MPI application.
1. this is non-portable, especially if the info argument is used.
Much easier to put the non-portability in mpirun arguments
than inside a program.
2. it is more complicated (since you have to mess with
intercommunicators)
3. it might be impossible to get high performance.
PVM provides good examples of this last one. If an application
is spawned in two parts on most MPPs (SP2, Paragon, for instance)
those two parts have to communicate through the daemon - they
can't use the native message passing. This means that
a portable implementation of MPI will not work on these machines.
This isn't to say we shouldn't make it possible to do what you
want to do, just that we shouldn't make it too easy, and we
shouldn't encourage it for applications that don't need it.
> Does this make sense? It's *definitely* the configuration I would use
> all the time if it were available, since my MPI applications are
> currently started by fork/exec from a parent process (the visual
> programming environment). Currently (with no spawn at all) I have to
> do this with an intervening shell script which starts all the MPI
> processes (with mpirun), and then make MPI process 0 the master and
> all the rest the slaves. If I could start the visual programming
> environment as usual and have it "become" an MPI process dynamically
> when someone requests a parallel operation, I could just MPI_Spawn all
> the slaves directly from the environment (which would be the master,
> saving me a process and a bunch of IPC).
Sounds like you have a good reason to spawn processes. Given the
current MPI-2 draft, I see no barrier to this. There is nothing preventing
your original process from "becoming" an MPI process by
calling MPI_Init(). It may be that current implementations require
it to be started by mpirun, but this is just an implementation
detail, oot a fundamental problem. Then you can spawn the rest
of the processes with MPI_Spawn. So I understand correctly?
Bill