[Mpi3-rma] MPI3 RMA proposals in general

[Douglas Miller]

I must admit I have not been able to properly follow all the discussions
going on, but as a casual observer and one-time implementer I have
concerns.

I don't see the problems that I had trying to optimize MPI RMA
implementations being addressed. It seems to me that having a robust API
that can't be implemented efficiently is as bad as having an insufficient
API.

The problems I had with MPI2 RMA seem to be centered on the fact that all
synchronization methods could be used on the same window indiscriminately
throughout the program. This makes it very difficult to optimize an
implementation because of all the corner-cases and state information that
must be dealt with. With new interfaces being heaped on top of old ones, I
see the problem only getting worse. It really seems to me that the MPI2 RMA
should be thrown out and redesigned.  I know that's not possible,
especially at this late time, and I hope I have not insulted anyone by
saying this. There's no need to respond to that statement (unless people
actually think that's a reasonable track).

But, what about having some restrictions on what synchronization that a
window will use. I would envision either different window types altogether
(e.g. MPI_Win_create_lock, MPI_Win_create_pscw, ...) or at least some sort
of assert parameter (which must be specified) to establish at cerate time
how a window will be synchronized. At the very least then, internally I
could add a function table to the window object that selected optimized
routines based on the window usage.

And, without eliminating (deprecating, etc) the existing API I don't see
how optimizations can be realized.

Hope I haven't kicked the proverbial hornets nest.

_______________________________________________
Douglas Miller                  BlueGene Messaging Development
IBM Corp., Rochester, MN USA                     Bldg 030-2 A410
dougmill at us.ibm.com               Douglas Miller/Rochester/IBM