You were only the sole dissenter because I had to catch a plane after the first
vote! I've been saying for months that the 1sided subcommittee has been putting
the cart before the horse, so to speak. (I know, this isn't quite what you're
saying, but it's close enough for me to jump in!)
> 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.
It's worse than that. At the moment, I am unaware of any implementors other
than maybe IBM who are willing to commit to implementing it *ever*. On the
other hand, I can think of at least three that are seriously interested in
*not* implementing it.
> 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.
Yup.
> 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.
We know right now that the performance is gonna be awful. Unfortunately, this
does not appear to be a priority; the subcommittee has made it quite clear on
numerous occasions that "flexibility" comes first. Which is strange,
considering the historical emphasis that MPI has placed on high performance.
The result is a whole lot of apathy from those of us with performance concerns.
But let's hear from the implementors! Who is willing to commit to a prototype
in the next 6 months? Anyone?
> 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.
Well, we certainly do need to follow proper procedure. Much as I hate it, there
*has* been a formal vote and so that does commit us to some degree to those
parts. On the other hand, we could always decide to "unvote" them...
I really think that, more than any other chapter in MPI-1 *or* MPI-2, the
1sided chapter has suffered tremendously from the committee nature of the MPI
Forum. I would suggest that if we're ever going to get it right, we need to
look at the chapter as a whole instead of voting in our favorite pieces one at
a time.
I'll even propose a starting point: What features (read: restrictions) must a
get/put interface have that, given reasonably intelligent machines, will allow
implementations to transfer data at hardware speeds? Neither latency nor
bandwidth may be sacrificed. Then, given a model which satisfies that, how do
we make it portable to the widest range of systems? Discuss.
> 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 am a bit more pessimistic. IMHO, waiting is highly unlikely to generate any
substantial feedback because prototype implementations will probably not appear
any time soon (see above). And this chapter has proven to be extremely
difficult to change in any meaningful way; in the past year, no less than three
different counter-proposals (Paul's, Lloyd's, and my own) have been suggested
in the names of performance and/or simplicity, only to be swallowed up. It
seems quite apparent that for whatever reason, the get/put proposal is not
going to change fundamentally from what it looks like now. Unless something
very significant happens to change that, we will eventually find ourselves in
the awkward position of either voting it in as it stands (and being left with a
mess) or killing it entirely (and having nothing to show for almost two years
of effort). Anyone wanna guess which outcome is the more likely?
> I would like to hold other chapters involving major change (including
> the Dynamic Process chapter) to the same standard.
Is there anything in MPI-2 that *doesn't* involve major change? Maybe the misc
chapter, but for the others I think that this is definitely the correct thing
to do.
Taking the specific example of the Dynamic Process chapter, I believe that both
LAM and MPICH already have prototype spawn() implementations in place, so it
looks like that particular chapter is well on its way. And I believe that the
MSU people have already done experiments with some of the collective
extensions, so that area also appears to be solidifying nicely. SGI will follow
both of these examples as soon as we are able, hopefully well before
Supercomputing.
-- Eric Salo Silicon Graphics Inc. "Do you know what the (415)933-2998 2011 N. Shoreline Blvd, 7L-802 last Xon said, just salo@sgi.com Mountain View, CA 94043-1389 before he died?"