[Mpi3-bwcompat] Teleconf tomorrow?

[Quincey Koziol]

Hi all,

On Oct 14, 2010, at 2:29 PM, Jeff Squyres wrote:

> 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?

        Yes, that's the basic idea.

        BTW, I think this is a perfectly acceptable solution (as much as I'd like a blue pony :-).  Fab was talking about just doing this, along with introducing MPI_Count, etc. for _future_ routines and getting a consensus from the forum that all future routines would use MPI_Count, etc.  Since it only duplicates a few functions now (they necessary ones to get the I/O and datatype routines working with large counts), it satisfies a lot of "agile" design guidelines and I think it might be a very reasonable thing to do.

        Quincey

>> 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/
> 
> 
> _______________________________________________
> Mpi3-bwcompat mailing list
> Mpi3-bwcompat_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat