I do also believe that the MPI forum is probably addressing topics that people
would like to see in a standard. But how many of these people thought that
they were asking for a 600-page standard containing hundreds of function calls?
> I confess that I am a little disappointed by the lack of response to the call
> for comments, but I am not distressed by it. I speak often in public about
> MPI, both 1 and 2, and the people I talk to seem happy about MPI-1, and happy
> about the topics being addressed in MPI-2, without being familiar with the
> current MPI-2 details.
Right. Again, they are happy about the topics. So am I.
> I am not particularly concerned with the size of the document. There has been
> a lot of work to do, and the Forum has done a lot of work.
There is no doubt that the forum has done a lot of work, and I'm sure that
there has been much benefit from it. Many researchers and vendors and
implementors have spoken with each other who otherwise might not have, and
they may have uncovered new semantic and syntactic problems related to
message passing, and they may have come up with new ways of handling old
problems, new software and hardware approaches, etc. I am definitely not
arguing that the MPI forum meetings were a waste of time.
But the public is not being asked to evaluate or comment on the meetings right
now, if I understand correctly. They are being asked to comment on the
standard which the forum has proposed. I, for one, think that that standard
is too large and complex.
By "too large", I don't necessarily mean the number of pages in the standards
document. I mean something that might be called "meme size" -- the number of
things which I must remember in order to understand and use the standard. For
example, if lots of functions have exactly the same argument list, then I
only need to remember the argument list and then the name and purpose of each
routine, whereas if every routine has a different argument list, I must
remember the name, description, and argument list for each separately. The
meme size would be closely related to the number of non-inherited methods in
an OO system. I suggest that the "meme size" for MPI is much too large for
your average application programmer, and that it could be made smaller.
Even though the MPI forum has one committee for each chapter, often containing
a number of parallel processing experts, the typical application program will
have but one programmer (or if more than one, each may need to understand MPI
in toto). To be workable, the entire MPI standard should be totally
comprehensible by any single person interested in using it, and certainly by
each of the members of the MPI forum. (Maybe this is latter part is already
the case, but I did not get that impression in the few meetings which I
attended.) Note that with larger APIs, such as X and Motif, for example, it
is quite common to be an "X hacker" who builds GUIs and has little or no
application-specific expertise. I'm not sure that it will make sense to be
an "MPI hacker". (Xt has about 231 functions and macros.)
I may be overstressing the importance of this simplification. I will leave it
to the forum to decide the target audience of MPI. It may be that there will
be enough projects, with enough person-hours devoted to learning the parts of
MPI that they need, to keep *this* MPI standard afloat. My guess is that most
people will use a subset consisting of a few functions from MPI-1, plus
some dynamic processes and maybe some I/O. But, in any case, I think the
standard would greatly benefit from any simplification, for both users and
implementors, even if it requires some modest compromises in performance on
some architectures. And in any case, I will still continue working on the
RISC end, and will expect CDS and its cousins to be a formidable competitor
to MPI if the standard is not simplified. (In case you lost the pointer I
gave you at SC'96, CDS is at http://www.nas.nasa.gov/NAS/Tools/Projects/CDS/)
> Just as MPI-1
> exposed some issues that require some complexity for a complete treatment
> (buffering, for example), so will MPI-2 expose some issues that require some
> complexity for a complete treatment (1-sided, I/O, and external,
> particularly). Maybe the presentation can be made more concise; maybe not.
> Standards definitions are notorious for being bad tutorial documents; the
> MPI-2 tutorial writings will no doubt emerge later, and will make it less
> intimidating for "the public".
The standard cannot be judged until it is understood. The standards document
can be judged by just trying to understand the standard.
> Rusty
-Dave
========================================================================
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