[Mpi3-bwcompat] Ticket 265 ready for review

Tue Feb 1 10:24:20 CST 2011

Well, I agree with Rajeev, and would like to see both this approach AND
a whole new set of MPI_<foo> functions with MPI_Aint Count (or some new
64bit integer possibly implementation specific MPI_Count datatype)
argument for convenience.  I would think a new major MPI revision (such
as MPI 3.0) is the time to introduce sweeping new classes of APIs,
otherwise it'll be another ten years or so until the next major revision
of the standard.

Of course providing backwards compatibility with MPI 2.2 (hopefully at
the binary level of a particular implementation) is a priority as well.
It would be nice if we could have both.

Geoff Paulsen
Platform MPI - http://www.platform.com/cluster-computing/platform-mpi

-----Original Message-----
From: mpi3-bwcompat-bounces_at_[hidden]
[mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff
Squyres
Sent: Friday, January 28, 2011 3:33 PM
To: MPI-3 backwards compatability WG
Subject: Re: [Mpi3-bwcompat] Ticket 265 ready for review

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