Re: [Mpi3-bwcompat] Ticket 265 ready for review
Yes, it is not absolutely required, but becomes a convenience feature. Rajeev On Jan 27, 2011, at 11:33 AM, Fab Tillier wrote:
Hi Rajeev,
Rajeev Thakur wrote on Wed, 26 Jan 2011 at 21:59:33
OK, thanks for the explanation.
If count is encapsulated in derived datatypes, we might need new datatype constructor functions that take MPI_Count, or at least a new MPI_Type_contiguous. Let's say the user wants to send an array of size X integers, where X is some weird number greater than 2G. If there is a new Type_contiguous, we have to see how it affects Type_get_envelope and Type_get_contents.
We shouldn't need new datatype creator functions for this to work - a user can nest types, for example by creating a struct type of contiguous types to achieve the length desired. In this case, the MPI_Type_get_envelope/contents would still work as currently defined.
Does that make sense?
Do we want to capture this discussion as comments on the ticket?
Thanks for the feedback! -Fab
Rajeev
On Jan 26, 2011, at 4:56 PM, Fab Tillier wrote:
Hi Rajeev,
Rajeev Thakur wrote on Wed, 26 Jan 2011 at 14:31:06
I wasn't at the last Forum meeting, so may have missed some of the background.
Is ticket #224 obsolete now? If so, you may want to indicate that in
Sorry, I've resolved it as withdrawn, with a comment that it was supersceded by 265.
Do MPI_Send/Recv etc. remain unchanged, i.e., no MPI_Count in them? If so, why do we need a new MPI_Get_count?
MPI_Send/Recv remain unchanged, and users are expected to create
derived datatypes to express data structures that are larger than 2^31 basic elements. Now that you point it out, though, I would think MPI_Get_elements is sufficient, as MPI_Get_count should be using the same datatype as used in the operation that transferred the data. Hoping that Jeff, Quincy, or David can chime in here and clarify why we need it.
Are the new "w" versions of the collectives specifically related to this ticket (i.e. to address the 64-bit count requirement) or are they a separate issue (i.e. a general need for array of datatypes instead of one datatype)?
By addressing the need for large counts via derived datatypes, we
effectively encapsulate the 'count' in the 'datatype' parameters. As an example, if you want to gather different 'counts' from different ranks where there is no common denominator, you would need to derive a datatype for each source rank, and specify those individual datatypes. That can't be done today, we can only specify different counts, but are limited by the 2^31 range of the count fields. So the missing 'w' functions allow the datatype to be used to encapsulate the count.
Minor typos: Two of the prototypes for Scatterw say Scatterv
instead.
Fixed, thanks.
-Fab
Rajeev
On Jan 26, 2011, at 3:38 PM, Fab Tillier wrote:
Ok folks, not a whole lot of time before the meeting, so it would
be
great if we could get everyone to read through the ticket and make sure I didn't miss something. I'd like to have David Solt generate a PDF sometime next week, in time for me to read it at the forum the following week (our time slot for this is 'working lunch' on Tuesday.
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265
Thanks for your help, -Fab
_______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat
_______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat
_______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat
_______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat
_______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat
participants (1)
-
unknown＠example.com