[Mpi3-bwcompat] Ticket 265 ready for review

Fri Jan 28 15:33:03 CST 2011

Rajeev --

The problem with your proposal is that it very, very quickly becomes a slippery slope of making a new MPI_<Foo>() with an MPI_Count argument for every value of <Foo>.

The Forum has soundly rejected every form of that.  This proposal is a (return to) just proposing absolute minimal functionality that is required for correctness.

On Jan 28, 2011, at 12:07 PM, Fab Tillier wrote:

> Rajeev Thakur wrote on Fri, 28 Jan 2011 at 08:09:29
> 
>> Yes, it is not absolutely required, but becomes a convenience feature.
> 
> I believe Quincy will be bringing forth a proposal to address this, but we wanted to get the minimum functionality to provide full support for large datatypes captured in a single ticket without adding convenience features.
> 
> -Fab
> 
>> 
>> 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
>>>> 224.
>>>>> 
>>>>> 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
>> 
>> 
>> _______________________________________________
>> 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

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