I know of no implmentation of the proposed MPI interface. My
understanding is that at this stage in MPI-1, there was an
implementation that tracked the current spec and provided substantial
feedback.
The major existing model is the Cray shmem interface, which is only
superficially similar. While the shmem interface has put and get
routines, the core of the proposal is really the semantics and the
synchronization mechanisms. The MPI mechanisms are quite different
from the Cray mechanisms. The Global Arrays package has been
mentioned but the MPI interface does not have equivalent functionality
- it would be a building block for GA. The vast majority of "existing
practice", shared memory and synchronization mechanisms on SMPs, is
completely different from the MPI proposal.
The lack of implementations would be ok if we had common practice,
or vice-versa. But it seems we are making a big mistake to standardize
out of thin air. So rather than rushing to take a second and final
vote on the 1sided chapter, I suggest that we await feedback from
initial implementations. The fact that we have a first formal vote
should give implementors the confidence that they are building on a
fairly solid surface. At the same time, if implementors find problems,
or if performance is unacceptable, or if users don't like the
functionality, we are not locked into a bad standard.
I suggest the delay even though I don't have any particular objections
to the proposal at this point. Further discussion of the parts which
have one formal vote is not necessary until there is feedback. I
think it is wise in any case to wait. If the proposal is solid, we
lose nothing and possibly gain earlier implementations. If the
proposal is broken, we have a much better chance to do something about
it. I do not see how this could delay progress, except superficially.
Someone will say that we can always override our earlier decision
if there is a problem. I submit that we will not have any
implementations by Supercomputing if there is no incentive to work on
a prototype, so this opportunity will not arise. Moreover,
procedurally it may be very difficult to make changes for all but the
most serious problems.
I would like to hold other chapters involving major change (including
the Dynamic Process chapter) to the same standard.
Comments?
Bill