July 2010 - Mpi3-bwcompat - mailman3.cels.anl.gov

Re: [Mpi3-bwcompat] MPI_Count mixing with int...
by unknown＠example.com 08 Jul '10

08 Jul '10

> As an aside, can count ever be larger than size_t? Probably not in the communication or I/O functions since count refers to the number of items in the memory buffer, but it could be for the datatype constructor functions since datatypes can represent file layout. Rajeev

1 0

Re: [Mpi3-bwcompat] MPI_Count mixing with int...
by unknown＠example.com 08 Jul '10

08 Jul '10

On Jul 8, 2010, at 1:32 PM, Quincey Koziol wrote: > > As an aside, can count ever be larger than size_t? > > I would imagine so - on a 32-bit CPU/system with a 64-bit file system. Oh ya, that whole filesystem thing. :-) But still -- why do you ask? I am hoping you don't plan to mention "size_t" in the standard at all... -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-bwcompat] MPI_Count mixing with int...
by unknown＠example.com 08 Jul '10

08 Jul '10

On Jul 8, 2010, at 11:26 AM, Fab Tillier wrote: > Quincey Koziol wrote on Thu, 8 Jul 2010 at 06:44:37 > >> >> On Jul 7, 2010, at 8:16 AM, Rajeev Thakur wrote: >> >>> Can we define both (to be the same) since we are familiar with count >>> for messages (it is a count of datatypes) and size for others. >> >> I agree - we shouldn't conflate counts and sizes, they are >> totally different things. Defining them both makes sense to me. > > But they are the same for the MPI_PACKED datatype, so really shouldn't be different. I'm not looking at the standard document right now, but that just strikes me as the standard being vague about the difference between the two. > As an aside, can count ever be larger than size_t? I would imagine so - on a 32-bit CPU/system with a 64-bit file system. Quincey > -Fab > >>>> -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] >>>> [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres >>>> Sent: Wednesday, July 07, 2010 7:24 AM To: MPI-3 backwards >>>> compatability WG Subject: Re: [Mpi3-bwcompat] MPI_Count mixing with >>>> int... >>>> >>>> On Jul 7, 2010, at 2:23 AM, Fab Tillier wrote: >>>> >>>>> Would anyone object if we defined MPI_Size rather than >>>> MPI_Count, and used it for count, position, and size >>>> parameters? We could then tackle the issues with >>>> MPI_Pack/Unpack/Pack_size/Type_size at the same time as >>>> counts. We can't use MPI_Aint here since we want to be able >>>> to be backward compatible, so must provide a separate type >>>> that can be defined as a standard integer. >>>> >>>> I agree that tackling them all at the same time is the Right >>>> Thing to do. I also agree with all your other points. >>>> >>>> I still am a little uncomfortable with the name "MPI_Size" >>>> because sizes and counts are theoretically different things. >>>> But then again, I can't think of a better name offhand... >>>> >>>> -- >>>> 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 >>>> >>> >>> _______________________________________________ >>> 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

1 0

Re: [Mpi3-bwcompat] MPI_Count mixing with int...
by unknown＠example.com 08 Jul '10

08 Jul '10

On Jul 8, 2010, at 12:26 PM, Fab Tillier wrote: > > I agree - we shouldn't conflate counts and sizes, they are > > totally different things. Defining them both makes sense to me. > > But they are the same for the MPI_PACKED datatype, so really shouldn't be different. ...and let's not forget that MPI_Aint's are used for displacements in MPI_GEt, MPI_PUT, and MPI_ACCUMULATE. :-\ Should we disentangle those, too? > As an aside, can count ever be larger than size_t? I don't think so, but why do you ask? -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-bwcompat] MPI_Count mixing with int...
by unknown＠example.com 08 Jul '10

08 Jul '10

Quincey Koziol wrote on Thu, 8 Jul 2010 at 06:44:37 > > On Jul 7, 2010, at 8:16 AM, Rajeev Thakur wrote: > >> Can we define both (to be the same) since we are familiar with count >> for messages (it is a count of datatypes) and size for others. > > I agree - we shouldn't conflate counts and sizes, they are > totally different things. Defining them both makes sense to me. But they are the same for the MPI_PACKED datatype, so really shouldn't be different. As an aside, can count ever be larger than size_t? -Fab >>> -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] >>> [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres >>> Sent: Wednesday, July 07, 2010 7:24 AM To: MPI-3 backwards >>> compatability WG Subject: Re: [Mpi3-bwcompat] MPI_Count mixing with >>> int... >>> >>> On Jul 7, 2010, at 2:23 AM, Fab Tillier wrote: >>> >>>> Would anyone object if we defined MPI_Size rather than >>> MPI_Count, and used it for count, position, and size >>> parameters? We could then tackle the issues with >>> MPI_Pack/Unpack/Pack_size/Type_size at the same time as >>> counts. We can't use MPI_Aint here since we want to be able >>> to be backward compatible, so must provide a separate type >>> that can be defined as a standard integer. >>> >>> I agree that tackling them all at the same time is the Right >>> Thing to do. I also agree with all your other points. >>> >>> I still am a little uncomfortable with the name "MPI_Size" >>> because sizes and counts are theoretically different things. >>> But then again, I can't think of a better name offhand... >>> >>> -- >>> 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 >>> >> >> _______________________________________________ >> 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

1 0

Re: [Mpi3-bwcompat] MPI_Count mixing with int...
by unknown＠example.com 08 Jul '10

08 Jul '10

On Jul 7, 2010, at 8:16 AM, Rajeev Thakur wrote: > Can we define both (to be the same) since we are familiar with count for > messages (it is a count of datatypes) and size for others. I agree - we shouldn't conflate counts and sizes, they are totally different things. Defining them both makes sense to me. Quincey > Rajeev > >> -----Original Message----- >> From: mpi3-bwcompat-bounces_at_[hidden] >> [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres >> Sent: Wednesday, July 07, 2010 7:24 AM >> To: MPI-3 backwards compatability WG >> Subject: Re: [Mpi3-bwcompat] MPI_Count mixing with int... >> >> On Jul 7, 2010, at 2:23 AM, Fab Tillier wrote: >> >>> Would anyone object if we defined MPI_Size rather than >> MPI_Count, and used it for count, position, and size >> parameters? We could then tackle the issues with >> MPI_Pack/Unpack/Pack_size/Type_size at the same time as >> counts. We can't use MPI_Aint here since we want to be able >> to be backward compatible, so must provide a separate type >> that can be defined as a standard integer. >> >> I agree that tackling them all at the same time is the Right >> Thing to do. I also agree with all your other points. >> >> I still am a little uncomfortable with the name "MPI_Size" >> because sizes and counts are theoretically different things. >> But then again, I can't think of a better name offhand... >> >> -- >> 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 >> > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] MPI_Count mixing with int...
by unknown＠example.com 07 Jul '10

07 Jul '10

Can we define both (to be the same) since we are familiar with count for messages (it is a count of datatypes) and size for others. Rajeev > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] > [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Wednesday, July 07, 2010 7:24 AM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI_Count mixing with int... > > On Jul 7, 2010, at 2:23 AM, Fab Tillier wrote: > > > Would anyone object if we defined MPI_Size rather than > MPI_Count, and used it for count, position, and size > parameters? We could then tackle the issues with > MPI_Pack/Unpack/Pack_size/Type_size at the same time as > counts. We can't use MPI_Aint here since we want to be able > to be backward compatible, so must provide a separate type > that can be defined as a standard integer. > > I agree that tackling them all at the same time is the Right > Thing to do. I also agree with all your other points. > > I still am a little uncomfortable with the name "MPI_Size" > because sizes and counts are theoretically different things. > But then again, I can't think of a better name offhand... > > -- > 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 >

1 0

Re: [Mpi3-bwcompat] MPI_Count mixing with int...
by unknown＠example.com 07 Jul '10

07 Jul '10

On Jul 7, 2010, at 2:23 AM, Fab Tillier wrote: > Would anyone object if we defined MPI_Size rather than MPI_Count, and used it for count, position, and size parameters? We could then tackle the issues with MPI_Pack/Unpack/Pack_size/Type_size at the same time as counts. We can't use MPI_Aint here since we want to be able to be backward compatible, so must provide a separate type that can be defined as a standard integer. I agree that tackling them all at the same time is the Right Thing to do. I also agree with all your other points. I still am a little uncomfortable with the name "MPI_Size" because sizes and counts are theoretically different things. But then again, I can't think of a better name offhand... -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-bwcompat] MPI-3 Backwards compat meeting tomorrow
by unknown＠example.com 07 Jul '10

07 Jul '10

On Jul 6, 2010, at 11:59 PM, Fab Tillier wrote: > Ok, I need a little Fortran help. :) Don't we all? :-) > Example 4.1.14, page 112, the calls to MPI_Type_vector passes a blocklength of 1. How do I change the example to specify that the '1' is of type MPI_COUNT_KIND? Do you mean example 4.1.13? I don't see the use of MPI_Type_vector in 4.1.14... The easiest way to pass a "1" of MPI_COUNT_KIND through as a parameter is to declare a new variable of that type and then pass that. I know there's a way to cast an integer to that type in the call to MPI_TYPE_VECTOR itself (i.e., without making a new variable), but I don't remember the exact syntax. INTEGER (kind = MPI_COUNT_KIND) :: count count = 1 ... call MPI_TYPE_VECTOR(9, count, 2, MPI_REAL, oneslice, ierr) Make sense? -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

MPI_Count mixing with int...
by unknown＠example.com 07 Jul '10

07 Jul '10

I'm going through the spec looking at examples that need updating, and came across example 4.22, which shows an interesting pattern that we may need to consider. Page 125, line 23, the call to MPI_Pack returns the postion as an output. This parameter is defined as an int in the standard. We thus can't type the position variable as an MPI_Count, otherwise taking the address and treating it like an int could leave some uninitialized bits. Then, on line 27, the buffer is sent, and position is used as the count of bytes, and in this case should be of type MPI_Count. Granted, in C the type will be promoted to MPI_Count, but there are subtle issues. I'll assert the following: 1. These two types should match. 2. The 'position' parameter to MPI_Pack and MPI_Unpack shouldn't be integers. 3. This should be extended to apply to the 'size' parameter to MPI_Type_size and MPI_Pack_size, which shouldn't be integers. This also applies to MPI_Pack for outsize, and MPI_Unpack for insize. While we could treat the second issue separately, the fact that the output parameter from MPI_Pack can be used as input to MPI_Send would suggest the two are fairly closely coupled: it doesn't make sense to have the range of the position type to MPI_Pack exceed the range of the count type to MPI_Send. The reverse could apply to MPI_Recv followed by MPI_Pack, thus MPI_Count shouldn't be greater in range than int or you could receive more than an integer's worth of MPI_PACKED data, and be unable to unpack it. Using these two parings {MPI_Pack, MPI_Send} and {MPI_Recv, MPI_Unpack} supports my first assertion above. Would anyone object if we defined MPI_Size rather than MPI_Count, and used it for count, position, and size parameters? We could then tackle the issues with MPI_Pack/Unpack/Pack_size/Type_size at the same time as counts. We can't use MPI_Aint here since we want to be able to be backward compatible, so must provide a separate type that can be defined as a standard integer. Thoughts? -Fab P.S. anyone feel like owning fixing the examples in the standard?

1 0