I don't understand this at all. All proposals to date have had the common
property that overlapping puts to the same region are disallowed - I think that
we probably all agree on that.
If you have many non-overlapping regions, then by definition they can be spilt
into seperate windows. If they do potentially overlap, then the application
must have some way of guaranteeing mutual exclusion, which is where the locks
and barriers come in.
Please elaborate, I'm probably missing the point entirely.
> PS: Please can someone explane whether any alternative model
> is better in efficiency or functionality than the main draft?
>
> In the moment they all seem to be worse because they need
> more unnecessary locks, barriers or cache flushes or invalidates.
In terms of implementation, it may or may not be easier; I'm still thinking
about this myself. However, it is simpler to understand because it contains
fewer concepts to master - window_in, window_out, rmw, fence, and window
counters are all gone. These are *very* confusing things!! How many of us can
truthfully claim to understand all of the subtle points and implications of the
current draft? I've been working on this for months and I still get confused.
Sure, I'm a bonehead, but there are a lot of us out there!
Marc's alternate proposal is a tremendous simplification. It captures most/all
of the functionality that everyone is claiming we need in a much cleaner
package. As Marc said, it is a higher level of abstraction.
> Eric wrote:
>
> Well, we want a model that is:
>
> 1) Easy to understand
> 2) Easy/possible to implement
> 3) Useful for applications
> 4) Portable
> 5) Fast
>
> I believe, that the user primarily wants
> *) Useful for applications
> *) Fast
> *) possible to implement on each platform
You've left out "Easy to understand", which I think would be a fatal mistake
for us to do in MPI-2. No one is gonna use any of this if they can't understand
it, and no one is gonna implement it if they can't understand it.
I agree with you that users don't care about ease of implementation - why
should they? But sometimes what they want simply isn't reasonable and then it's
up to the implementors to say no. (Example: multicast)
-- Eric Salo Silicon Graphics Inc. "Do you know what the (415)933-2998 2011 N. Shoreline Blvd, 8U-808 last Xon said, just salo@sgi.com Mountain View, CA 94043-1389 before he died?"