[Mpi3-bwcompat] Teleconf tomorrow?

[Jeff Squyres]

On Oct 14, 2010, at 2:54 PM, Fab Tillier wrote:

> I'd like to find a solution that allows mixing int and int64 (or whatever) counts in a single application (whether all in the app's source, or a mixture of app + third-party library.)  This is one of the main weaknesses of the current proposal, and one of the benefits of just having a full set of suffixed functions.

Yes, I agree -- I discussed this with Adam, Bill, and Torsten at dinner and only then did I understand the objection that Ralf raised in the room (mixing int and int64 in the same app).

> I think what I want to see is a full set of MPI3_Send, etc functions, that fix the count, the sizes, the ranks, the tags, etc.

This is the conclusion we came to at dinner, too.  Might end up putting in piggybacking (acck!!) and other stuff in there, too.  ...but we'd love to see someone else's proposal for that.  ;-)

> The goals to me are:
> 1. Support for codes that use int (can't break existing code.)
> 2. Support for modern codes (things aren't int.)
> 3. Support for mixed codes (both int and not int.)

Agreed.  The echo "MPI_Send(..., int count,...)" | sed -e 's/int count/MPI_Count count/'g proposal addresses #1 and #2.  #3 was not addressed.

> What's the best way of providing the above?  What if we fix MPI_Tag and MPI_Rank at the same time, does it change the preferred solution?

I think that having a new MPI3_Send with all the fixes in it (MPI_Count, MPI_Tag, MPI_Rank, and a blue pony) is probably the best solution.  I'm sure we'll dither about the suffix for what to call this new function, though.  ;-)

> The three options are:
> 1. Suffix all APIs, fix count & size, optionally fix tag and rank.

...and probably some other stuff will get wedged in there, eventually (e.g., piggybacking).

> 2. Add just the bare minimum, leverage datatypes to work around counts.  Note that this requires introducing w versions of v collective APIs, to allow for different types (since the v functions allow different counts from each participant.)

This option also includes the "output" functions, right?

> 3. Introduce count & size, modify existing APIs.

Don't forget:

4. Ostrich (stick head in sand / do nothing).

5. Introduce new text that strictly disallows communicating with more than 2B count of anything.

6. Impose hefty fines on anyone who does.

7. Get the IRS involved.


-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/