> I would have to agree that most users at our site will probably
> never touch MPI-2, with a possible exception of some I/O functions.
> On the other hand, I thought MPI-2 was for parallel pre-processors,
> library writers and tool builders! Those who regularly get their
> hands dirty developing portable parallel tools will certainly benefit
> from much of MPI-2.
Since I consider myself a tool builder, I'll answer.
There is no doubt that the whole "communicator" idea is an aid to library
writers. This can be added to any message-passing system. In fact, didn't
it start in Zipcode?
I agree that the MPI-I/O stuff is pretty good. I am not sure that making it
part of MPI has increased its value, however. I think I might like it more if
I didn't need to hassle with MPI to use it.
As for using MPI for preprocessors and tools, I would have to say that MPI
is only a good choice based on the absence of other choices. In fact, when
MPI-1 first started heading toward a non-layered system with no decent support
for shared memory, and it began collecting operations like "ready send",
I recognized that I would not want to build tools upon it, and started my
own substrate, CDS. This decision was further cemented by decisions made
in MPI-2, especially concerning restrictions in dynamic process creation,
and the fact that one-sided operations still involve copying. (Would you
want to program with an HPF compiler which produced programs which internally
copied data even if the processes which were communicating were on the same
node?) If MPI was developed for the tool builder and not the applications
programmer, then it sure is a lot of work for a relatively small end-user
population, and I, as a tool-builder, would have liked to know that I might
have had a stronger voice.
Regardless of who the end-user will be, the answer will be in the marketplace.
If MPI can benefit the tool-builder or the preprocessor writer more than other
approaches (like CDS, or Nexus, or ...), then great. MPI has some leverage
in that the forum calls it a standard, but this is mostly marketing. (I heard
MPI called a "de facto standard" even when MPICH was the only extant
implementation, and there were virtually no programs written using MPI yet.)
MPI's partial success over PVM can be attributed to MPI's ability to pass
messages with fewer calls and less copying in some cases -- i.e. market
forces -- not because it was "more standard" in some sense. We shall see,
then, whether MPI can succeed on its own merits against new lean and mean
entries into the field, especially considering the years and PhD-months it
apparently takes to update MPI. As always, I could be wrong...
-Dave
(P.S. If there are followups on mpi-comment, I can't see them because
majordomo has delayed my subscription.)
========================================================================
David C. DiNucci | MRJ, Inc., Rsrch Scntst | NASA Ames Rsrch Ctr
dinucci@nas.nasa.gov| NAS (Num. Aerospace Sim.)| M/S T27A-2
(415)604-4430 | Parallel Tools Team | Moffett Field, CA 94035