March 2011 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] MPI_Count "ticket 0" updates
by Jeff Squyres 18 Mar '11

18 Mar '11

...and we missed one "e.g.," that Adam wanted. Now fixed. So here's a question: do these "ticket 0" kinds of changes reset the clock on the formal reading? --> Yes, they should. We have reset the clock on tickets for smaller things than this before. --> No, they should not. The whole concept of "ticket 0" is to be a kinder, gentler Forum in an attempt to lower the bar to readability fixes. What do you think? If they do reset the clock, we'll happily discard them and go back to the PDF that was sent on Monday (i.e., that PDF is still available on #265). None of Adam's changes affect the meaning of the proposed text; they just make it read better. We'll then introduce the "ticket 0" changes when (if) the MPI_Count changes are voted in (i.e.: we do not want to reset the clock). On Mar 18, 2011, at 8:13 AM, Jeff Squyres wrote: > Adam Moody provided a bunch of "ticket 0"-esque updates to the MPI_Count text. I have uploaded a new PDF to the ticket: > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 > > For those who can't uncompress .bz2 files, I uploaded a full PDF here: > > http://www.open-mpi.org/~jsquyres/one-count-to-rule-them-all/ > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

MPI_Count "ticket 0" updates
by Jeff Squyres 18 Mar '11

18 Mar '11

Adam Moody provided a bunch of "ticket 0"-esque updates to the MPI_Count text. I have uploaded a new PDF to the ticket: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 For those who can't uncompress .bz2 files, I uploaded a full PDF here: http://www.open-mpi.org/~jsquyres/one-count-to-rule-them-all/ -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-forum] First reading: MPI_Count
by Adam T. Moody 17 Mar '11

17 Mar '11

Hi Fab, No problem. I've inlined some replies. -Adam Fab Tillier wrote: >Hi Adam, > >Thanks for the feedback, comments inline. > >Adam T. Moody wrote on Wed, 16 Mar 2011 at 17:20:42 > > > >>Wow, I should have proof-read my email first. Lots of typos. See >>inlined fixes for these. >>-Adam >> >>Adam T. Moody wrote: >> >> >> >>>Hi Jeff, >>>Ugh, this whole chapter (not the count ticket itself) needs major >>> >>> >>> >>this whole chapter = the datatypes chapter. >> >> >> >>>editing. It's poorly organized and it talks about and uses deprecated >>>concepts all over the place. I'll work with Quincey to propose a better >>>version (along with a full set of MPI_Count datatype calls). >>> >>>Here are some comments for the count ticket. >>> >>>p 16, line 15 >>>Change >>> "Derived datatypes can be created representing more elements than >>>can be encoded in a C int or Fortran INTEGER. MPI_GET_COUNT, >>>MPI_GET_ELEMENTS, and associated functions cannot properly express >>>these quantities. To overcome this limitation, these quatities are >>>declared to be INTEGER (KIND=MPI_COUNT_KIND) in Fortran. In C, one >>>uses MPI_Count." to >>> "As described above, MPI defines one type to address locations >>>within memory and another type to address locations within a file. >>>However, at times, one needs a single type that can be used to address >>>locations within either memory or a file. Furthermore, one needs this >>> >>> >>> >>or a file, and furthermore, one needs this type to encode any value >>stored in a C int or Fortran INTEGER. >> >> > >How about: >"As described above, MPI defines one type (MPI_Aint) to address locations within memory and another type (MPI_Offset) to address locations within files. In addition, some MPI procedures use count arguments that represent a number of MPI datatypes on which to operate. At times one needs a single type that can be used to address locations within either memory of files as well as express count values. The datatype of such an argument is MPI_Count in C, and INTEGER(KIND=MPI_COUNT_KIND) in Fortran. These types must have the same width and encode values in the same manner such that count values in one language may be passed directly to another language without conversion." > >This is more in line with the descriptions for MPI_Aint and MPI_Offset and more explicit as to the motivation, but without the explicit reference to MPI procedures. > > Yes, this sounds fine. I wrote my version to avoid the word "datatype". Memory and files are well-known, but datatypes in the way MPI uses them are new to most people. Since the concept is not well defined at this point in the text, I was trying to write something that avoided using the term. Probably not a big deal to use it though. I thought about referencing "MPI_Aint" and "MPI_Offset", but those are really just the C types, not the generic name. I don't know that we even have a generic (language neutral) term for each concept. And now that I re-read it, technically, MPI defines more than one type for each, so my use of "one type" is not quite right either. Maybe modify it a bit to read something like "MPI defines types to address locations within memory (e.g., MPI_Aint) ...". > > >>>type to also any value stored in a C int or Fortran INTEGER. For this, >>>MPI defines the datatype MPI_Count in C and INTEGER >>>(KIND=MPI_COUNT_KIND) in Fortran." >>> >>>p 16, line 23-24 >>>Change >>> "in a variable of type C int, MPI_Aint, MPI_Offset, or Fortran >>> INTEGER." to "in a variable of type int, MPI_Aint, or MPI_Offset in >>> C and Fortran >>>INTEGER, INTEGER(KIND=MPI_ADDRESS_KIND), or INTEGER >>>(KIND=MPI_OFFSET_KIND) in Fortran." >>> >>> >>> >>in C and of type INTEGER, INTEGER(KIND=MPI_ADDRESS_KIND), or INTEGER >>(KIND=MPI_OFFSET_KIND) in Fortran. >> >> > >Sounds good. > > > >>>p 99, line 14-18 >>>The whole paragraph is all about the old stuff, which just confuses a >>>new reader. I would just drop it (or move it toward the end), and >>>replace it with something like: >>> "The following functions return the lower bound and the extent of a >>>datatype." >>> >>> > >This paragraph was there already, and I wanted to minimize the changes: I simply updated the text to reference the _x version too. I'm reluctant to remove the whole paragraph - it should be no more confusing than the text that's already in MPI 3.0 draft 1. > > That's fine. I'll be putting together a ticket to clean up this chapter, so I'll address it then. > > >>It turns out that a statement like this one is listed below the >>functions. No need to list it twice, so either drop this one or drop >>the similar statement after the functions. >> >> >> >>>If on the otherhand we want to leave, it there are some typos (extra >>>period after MPI_TYPE_EXTENT >>> >>> > >Thanks, fixing this. > > > >>>and "address sized integers" probably >>>means MPI_ADDRESS_KIND, so we should just say "larger sized integers" >>>or something like that): >>> >>> > >INTEGER(KIND=MPI_ADDRESS_KIND) may not be larger than INTEGER. In any case, "address sized integers" is existing text. > > Sure, that's fine. I'll try to kill/move this paragraph later in my 'clean up the chapter' ticket. > > >>> "MPI_TYPE_EXTENT. and also return address sized integers" --> >>>"MPI_TYPE_EXTENT and also return larger sized integers" >>>I vote to just drop and replace it, though. >>> >>> > >I think dropping this would belong in a different 'cleanup the text' ticket. > > > >>>Question: What if MPI_TYPE_GET_EXTENT overflows? >>> >>> > >Is MPI_UNDEFINED a legit value to return in this case? The current standard doesn't define overflow semantics, so I would argue that this isn't a deficiency in this ticket. > >However, should we deprecate MPI_TYPE_GET_EXTENT since MPI_TYPE_GET_EXTENT_X supersedes its functionality? > > I would think returning MPI_UNDEFINED would make sense here. We are adding the MPI_UNDEFINED semantic to a similar query where it didn't exist before, namely MPI_GET_ELEMENTS (p106, line 22), so why not add it to GET_EXTENT, GET_SIZE, and GET_TRUE_EXTENT, as well. Maybe we should push all of this off to an "overflow" ticket? A separate but related question: We now have multiple functions that return the constant "MPI_UNDEFINED". In some cases, the MPI_UNDEFINED is returned in an int, and in others its returned in an MPI_Count. Internally within the MPI implementation, MPI_UNDEFINED will be defined some datatype, but it can't be both. Does it matter that we're using the same constant for comparison of different datatypes? Hopefully, casting will come to the rescue, but I haven't thought about this much. > > >>>p 100, line 48 >>> "MPI_TYPE_GET_TRUE_EXTENT and ..." --> "The functions >>>MPI_TYPE_GET_TRUE_EXTENT and ..." >>> >>> > >Ok. > > > >>>p 105, line 27 >>> "query function MPI_GET_ELEMENTS." --> "query functions >>>MPI_GET_ELEMENTS or MPI_GET_ELEMENTS_X." >>> >>> > >Ok. > > > >>>p 106, line 20 >>> "the MPI_GET_COUNT sets the value of count to" --> "the function >>>sets the value of count to" >>> >>> > >No, this paragraph is discussing MPI_GET_ELEMENTS and MPI_GET_ELEMENTS_X, so using 'the function' is ambiguous, especially since it's referring to MPI_GET_COUNT. > > You're right. Hmm, I have no idea what I was thinking here. > > >>>p 106, line 20 Move sentence about overflow up to other sentence about >>>MPI_UNDEFINED, and reword it a bit. >>> >>> > >First sentence about MPI_UNDEFINED relates to MPI_COUNT (odd place for it if you ask me, but that's the way the text is setup today. Ideally the whole sentence on line 19 "If the number of basic elements ... MPI_GET_COUNT sets the value of count to MPI_UNDEFINED" would be in the text describing MPI_GET_COUNT. > > > >>> "Furthermore, if the number of basics elements is an integral number >>>of datatype copies but this magnitude of this value exceeds the limits >>>of the count parameter, then the function sets the value of count to >>>MPI_UNDEFINED." >>> >>> > >The "is an integral number of datatype copies" bit applies to MPI_GET_COUNT. > > Ah, yes, right again. I think I was mixing the roles of the operations here, which led to my confusion. > > >>number of *basic* elements ... copies but *the* magnintude of this ... >> >> > >How about "If the number of basic elements exceeds the limits of the count parameter, then the function sets the value of count to MPI_UNDEFINED."? > >Thanks, >-Fab > > > >>>-Adam >>> >>> >>> >>>Jeff Squyres wrote: >>> >>> >>> >>> >>> >>>>PDFs have been attached to the 2 MPI_Count tickets for a formal >>>>reading at the Chicago Forum meeting in 2 weeks: >>>> >>>>- General MPI_Count ticket >>>>https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >>>>- "W" versions of some collectives >>>>https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/269 >>>> >>>>Remember that the solution we're proposing here is the "minimal" >>>> >>>> >>MPI_Count approach: adding a small number of new functions that take >>MPI_Count arguments so that MPI can claim to fully support arbitrary-sized >>counts. >> >> >>>>Enjoy your light reading. :-) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>mpi-forum mailing list >>>mpi-forum(a)lists.mpi-forum.org >>>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >>> >>> >>> >>_______________________________________________ >>mpi-forum mailing list >>mpi-forum(a)lists.mpi-forum.org >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> > >_______________________________________________ >mpi-forum mailing list >mpi-forum(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >

1 0

Re: [Mpi-forum] First reading: MPI_Count
by Fab Tillier 17 Mar '11

17 Mar '11

Hi Adam, Thanks for the feedback, comments inline. Adam T. Moody wrote on Wed, 16 Mar 2011 at 17:20:42 > Wow, I should have proof-read my email first. Lots of typos. See > inlined fixes for these. > -Adam > > Adam T. Moody wrote: > >> Hi Jeff, >> Ugh, this whole chapter (not the count ticket itself) needs major >> > this whole chapter = the datatypes chapter. > >> editing. It's poorly organized and it talks about and uses deprecated >> concepts all over the place. I'll work with Quincey to propose a better >> version (along with a full set of MPI_Count datatype calls). >> >> Here are some comments for the count ticket. >> >> p 16, line 15 >> Change >> "Derived datatypes can be created representing more elements than >> can be encoded in a C int or Fortran INTEGER. MPI_GET_COUNT, >> MPI_GET_ELEMENTS, and associated functions cannot properly express >> these quantities. To overcome this limitation, these quatities are >> declared to be INTEGER (KIND=MPI_COUNT_KIND) in Fortran. In C, one >> uses MPI_Count." to >> "As described above, MPI defines one type to address locations >> within memory and another type to address locations within a file. >> However, at times, one needs a single type that can be used to address >> locations within either memory or a file. Furthermore, one needs this >> > or a file, and furthermore, one needs this type to encode any value > stored in a C int or Fortran INTEGER. How about: "As described above, MPI defines one type (MPI_Aint) to address locations within memory and another type (MPI_Offset) to address locations within files. In addition, some MPI procedures use count arguments that represent a number of MPI datatypes on which to operate. At times one needs a single type that can be used to address locations within either memory of files as well as express count values. The datatype of such an argument is MPI_Count in C, and INTEGER(KIND=MPI_COUNT_KIND) in Fortran. These types must have the same width and encode values in the same manner such that count values in one language may be passed directly to another language without conversion." This is more in line with the descriptions for MPI_Aint and MPI_Offset and more explicit as to the motivation, but without the explicit reference to MPI procedures. >> type to also any value stored in a C int or Fortran INTEGER. For this, >> MPI defines the datatype MPI_Count in C and INTEGER >> (KIND=MPI_COUNT_KIND) in Fortran." >> >> p 16, line 23-24 >> Change >> "in a variable of type C int, MPI_Aint, MPI_Offset, or Fortran >> INTEGER." to "in a variable of type int, MPI_Aint, or MPI_Offset in >> C and Fortran >> INTEGER, INTEGER(KIND=MPI_ADDRESS_KIND), or INTEGER >> (KIND=MPI_OFFSET_KIND) in Fortran." >> > in C and of type INTEGER, INTEGER(KIND=MPI_ADDRESS_KIND), or INTEGER > (KIND=MPI_OFFSET_KIND) in Fortran. Sounds good. >> p 99, line 14-18 >> The whole paragraph is all about the old stuff, which just confuses a >> new reader. I would just drop it (or move it toward the end), and >> replace it with something like: >> "The following functions return the lower bound and the extent of a >> datatype." This paragraph was there already, and I wanted to minimize the changes: I simply updated the text to reference the _x version too. I'm reluctant to remove the whole paragraph - it should be no more confusing than the text that's already in MPI 3.0 draft 1. > It turns out that a statement like this one is listed below the > functions. No need to list it twice, so either drop this one or drop > the similar statement after the functions. > >> If on the otherhand we want to leave, it there are some typos (extra >> period after MPI_TYPE_EXTENT Thanks, fixing this. >> and "address sized integers" probably >> means MPI_ADDRESS_KIND, so we should just say "larger sized integers" >> or something like that): INTEGER(KIND=MPI_ADDRESS_KIND) may not be larger than INTEGER. In any case, "address sized integers" is existing text. >> "MPI_TYPE_EXTENT. and also return address sized integers" --> >> "MPI_TYPE_EXTENT and also return larger sized integers" >> I vote to just drop and replace it, though. I think dropping this would belong in a different 'cleanup the text' ticket. >> Question: What if MPI_TYPE_GET_EXTENT overflows? Is MPI_UNDEFINED a legit value to return in this case? The current standard doesn't define overflow semantics, so I would argue that this isn't a deficiency in this ticket. However, should we deprecate MPI_TYPE_GET_EXTENT since MPI_TYPE_GET_EXTENT_X supersedes its functionality? >> p 100, line 48 >> "MPI_TYPE_GET_TRUE_EXTENT and ..." --> "The functions >> MPI_TYPE_GET_TRUE_EXTENT and ..." Ok. >> p 105, line 27 >> "query function MPI_GET_ELEMENTS." --> "query functions >> MPI_GET_ELEMENTS or MPI_GET_ELEMENTS_X." Ok. >> p 106, line 20 >> "the MPI_GET_COUNT sets the value of count to" --> "the function >> sets the value of count to" No, this paragraph is discussing MPI_GET_ELEMENTS and MPI_GET_ELEMENTS_X, so using 'the function' is ambiguous, especially since it's referring to MPI_GET_COUNT. >> p 106, line 20 Move sentence about overflow up to other sentence about >> MPI_UNDEFINED, and reword it a bit. First sentence about MPI_UNDEFINED relates to MPI_COUNT (odd place for it if you ask me, but that's the way the text is setup today. Ideally the whole sentence on line 19 "If the number of basic elements ... MPI_GET_COUNT sets the value of count to MPI_UNDEFINED" would be in the text describing MPI_GET_COUNT. >> "Furthermore, if the number of basics elements is an integral number >> of datatype copies but this magnitude of this value exceeds the limits >> of the count parameter, then the function sets the value of count to >> MPI_UNDEFINED." The "is an integral number of datatype copies" bit applies to MPI_GET_COUNT. > number of *basic* elements ... copies but *the* magnintude of this ... How about "If the number of basic elements exceeds the limits of the count parameter, then the function sets the value of count to MPI_UNDEFINED."? Thanks, -Fab > >> -Adam >> >> >> >> Jeff Squyres wrote: >> >> >> >>> PDFs have been attached to the 2 MPI_Count tickets for a formal >>> reading at the Chicago Forum meeting in 2 weeks: >>> >>> - General MPI_Count ticket >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >>> - "W" versions of some collectives >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/269 >>> >>> Remember that the solution we're proposing here is the "minimal" > MPI_Count approach: adding a small number of new functions that take > MPI_Count arguments so that MPI can claim to fully support arbitrary-sized > counts. >>> >>> Enjoy your light reading. :-) >>> >>> >>> >>> >>> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] Significant discussion point with Ticket 269
by Fab Tillier 17 Mar '11

17 Mar '11

Adam T. Moody wrote on Thu, 17 Mar 2011 at 12:43:49 > Fab Tillier wrote: > >> Hi Adam, >> >> -----Original Message----- From: mpi-forum-bounces(a)lists.mpi-forum.org >> [mailto:mpi-forum- bounces(a)lists.mpi-forum.org] On Behalf Of Adam T. >> Moody Sent: Wednesday, March 16, 2011 5:47 PM >> >>> The displacements in the new w functions are not semantically the same >>> as in Alltoallw. See p 146, lines 41-44 vs p 169, line 26. In >>> alltoallw, the displacements are given in number of bytes from the >>> start of the buffer, but for the new functions, they are given as an >>> integer number of extents of the corresponding datatype. >> >> The displacement parameters are identical in definition to those of the 'V' >> variants of those functions, only the datatype (recvtype and/or sendtype) >> was turned to an array and pluralized. I had missed the difference between >> MPI_Alltoallv and MPI_Alltoallw, thanks for catching that. >> >>> First, we should be consistent with alltoallw or otherwise use a >>> suffix other than 'w'. >> >> I don't know that we can succeed in achieving our goals of allowing users to >> use large datatypes if we change to byte counts without going to a different >> (larger) datatype - an 'int' may not be enough displacement for a single >> datatype. If we are to change the suffix and use different parameters, let's >> not mess around with using integer counts and just go to MPI_Count too, not >> just the displacements. If we consider going to MPI_Count for count >> parameters, we might as well just stick with a MPI_Count version of the 'v' >> functions and avoid the 'w' all together. > > For the sake of discussion, let's go with 'x', and then like you > suggest, we could create an 'x' set by extending all of the 'v' > collectives to take MPI_Count instead of int. I think that could work. > >>> Second, specifying the displacement in terms of datatype extents >>> restricts some codes from using these functions. For example, in >>> gatherw, what if the root needs to receive a 2-byte datatype starting >>> at byte position 1 in its receive buffer? I don't think this can be >>> done under the current definition. >> >> Can't a user resize the datatype and set a LB so that the received >> datatype is offset by 1 byte? >> > You're right. That would work. The down side is that this may require > a user to create one datatype for each process, where I'm guessing most > apps can use the same datatype (or a small set of different datatypes) > in many cases but only change the displacement. In this case, it would > be possible, but it's ugly. Having the displacement in alltoallw in bytes but specified as an int, especially since it's always relative to sendbuf, is just terrible. If displacements are going to be integers, I strongly believe they cannot be in units of bytes and still be useful, especially since the main motivation for introducing these new collectives is to allow large counts to be encapsulated in derived datatypes. The bottom line is that the inconsistency between alltoallw and the new 'w' functions is a result of alltoallw being poorly defined. We shouldn't define the new 'w' functions as badly just for consistency's sake. >>> Third, if we decide to define the displacement in bytes, as alltoallw >>> does, then we should really think about making the displacement >>> datatype an MPI_Aint, or perhaps even MPI_Count. Using an int >>> datatype will lead to other problems. >> >> If we change these new functions to use MPI_Aint, then we should really >> create a new version of Alltoallw to match. There are other functions that >> use the wrong 'type' for parameters so we need to be careful about 'the >> slippery slope'. > > Yes, I agree. Of these ideas so far, I'm leaning toward the 'x' > extension of the 'v' collectives, but I need to think about it more. My goal with this ticket was to get minimal "complete" functionality for large derived types. My hope was always that it would be replaced before MPI3 is finalized with something better, but driven by *somebody else*. If it didn't get replaced, at least the standard would provide full (though cumbersome) functionality. -Fab >> Oy, the baggage we have to deal with to preserve back compat... >> >> -Fab >> >>> -Adam >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] Significant discussion point with Ticket 269
by Adam T. Moody 17 Mar '11

17 Mar '11

Fab Tillier wrote: >Hi Adam, > >-----Original Message----- >From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Adam T. Moody >Sent: Wednesday, March 16, 2011 5:47 PM > > > >>The displacements in the new w functions are not semantically the same as in Alltoallw. >>See p 146, lines 41-44 vs p 169, line 26. In alltoallw, the displacements are given in number >>of bytes from the start of the buffer, but for the new functions, they are given as an integer >>number of extents of the corresponding datatype. >> >> > >The displacement parameters are identical in definition to those of the 'V' variants of those functions, only the datatype (recvtype and/or sendtype) was turned to an array and pluralized. I had missed the difference between MPI_Alltoallv and MPI_Alltoallw, thanks for catching that. > > > >>First, we should be consistent with alltoallw or otherwise use a suffix other than 'w'. >> >> > >I don't know that we can succeed in achieving our goals of allowing users to use large datatypes if we change to byte counts without going to a different (larger) datatype - an 'int' may not be enough displacement for a single datatype. If we are to change the suffix and use different parameters, let's not mess around with using integer counts and just go to MPI_Count too, not just the displacements. If we consider going to MPI_Count for count parameters, we might as well just stick with a MPI_Count version of the 'v' functions and avoid the 'w' all together. > > For the sake of discussion, let's go with 'x', and then like you suggest, we could create an 'x' set by extending all of the 'v' collectives to take MPI_Count instead of int. I think that could work. > > >>Second, specifying the displacement in terms of datatype extents restricts some codes >>from using these functions. For example, in gatherw, what if the root needs to receive a >>2-byte datatype starting at byte position 1 in its receive buffer? I don't think this can be done >>under the current definition. >> >> > >Can't a user resize the datatype and set a LB so that the received datatype is offset by 1 byte? > > You're right. That would work. The down side is that this may require a user to create one datatype for each process, where I'm guessing most apps can use the same datatype (or a small set of different datatypes) in many cases but only change the displacement. In this case, it would be possible, but it's ugly. > > >>Third, if we decide to define the displacement in bytes, as alltoallw does, then we should really >>think about making the displacement datatype an MPI_Aint, or perhaps even MPI_Count. Using >>an int datatype will lead to other problems. >> >> > >If we change these new functions to use MPI_Aint, then we should really create a new version of Alltoallw to match. There are other functions that use the wrong 'type' for parameters so we need to be careful about 'the slippery slope'. > > Yes, I agree. Of these ideas so far, I'm leaning toward the 'x' extension of the 'v' collectives, but I need to think about it more. >Oy, the baggage we have to deal with to preserve back compat... > >-Fab > > > >>-Adam >> >> >> >>_______________________________________________ >>mpi-forum mailing list >>mpi-forum(a)lists.mpi-forum.org >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> >> >> > >_______________________________________________ >mpi-forum mailing list >mpi-forum(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >

1 0

Re: [Mpi-forum] Significant discussion point with Ticket 269
by Fab Tillier 17 Mar '11

17 Mar '11

Hi Adam, -----Original Message----- From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Adam T. Moody Sent: Wednesday, March 16, 2011 5:47 PM > The displacements in the new w functions are not semantically the same as in Alltoallw. > See p 146, lines 41-44 vs p 169, line 26. In alltoallw, the displacements are given in number > of bytes from the start of the buffer, but for the new functions, they are given as an integer > number of extents of the corresponding datatype. The displacement parameters are identical in definition to those of the 'V' variants of those functions, only the datatype (recvtype and/or sendtype) was turned to an array and pluralized. I had missed the difference between MPI_Alltoallv and MPI_Alltoallw, thanks for catching that. > First, we should be consistent with alltoallw or otherwise use a suffix other than 'w'. I don't know that we can succeed in achieving our goals of allowing users to use large datatypes if we change to byte counts without going to a different (larger) datatype - an 'int' may not be enough displacement for a single datatype. If we are to change the suffix and use different parameters, let's not mess around with using integer counts and just go to MPI_Count too, not just the displacements. If we consider going to MPI_Count for count parameters, we might as well just stick with a MPI_Count version of the 'v' functions and avoid the 'w' all together. > Second, specifying the displacement in terms of datatype extents restricts some codes > from using these functions. For example, in gatherw, what if the root needs to receive a > 2-byte datatype starting at byte position 1 in its receive buffer? I don't think this can be done > under the current definition. Can't a user resize the datatype and set a LB so that the received datatype is offset by 1 byte? > Third, if we decide to define the displacement in bytes, as alltoallw does, then we should really > think about making the displacement datatype an MPI_Aint, or perhaps even MPI_Count. Using > an int datatype will lead to other problems. If we change these new functions to use MPI_Aint, then we should really create a new version of Alltoallw to match. There are other functions that use the wrong 'type' for parameters so we need to be careful about 'the slippery slope'. Oy, the baggage we have to deal with to preserve back compat... -Fab > -Adam > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >

1 0

Significant discussion point with Ticket 269
by Adam T. Moody 16 Mar '11

16 Mar '11

The displacements in the new w functions are not semantically the same as in Alltoallw. See p 146, lines 41-44 vs p 169, line 26. In alltoallw, the displacements are given in number of bytes from the start of the buffer, but for the new functions, they are given as an integer number of extents of the corresponding datatype. First, we should be consistent with alltoallw or otherwise use a suffix other than 'w'. Second, specifying the displacement in terms of datatype extents restricts some codes from using these functions. For example, in gatherw, what if the root needs to receive a 2-byte datatype starting at byte position 1 in its receive buffer? I don't think this can be done under the current definition. Third, if we decide to define the displacement in bytes, as alltoallw does, then we should really think about making the displacement datatype an MPI_Aint, or perhaps even MPI_Count. Using an int datatype will lead to other problems. -Adam

1 0

Re: [Mpi-forum] First reading: MPI_Count
by Adam T. Moody 16 Mar '11

16 Mar '11

Wow, I should have proof-read my email first. Lots of typos. See inlined fixes for these. -Adam Adam T. Moody wrote: >Hi Jeff, >Ugh, this whole chapter (not the count ticket itself) needs major > > this whole chapter = the datatypes chapter. >editing. It's poorly organized and it talks about and uses deprecated >concepts all over the place. I'll work with Quincey to propose a better >version (along with a full set of MPI_Count datatype calls). > >Here are some comments for the count ticket. > >p 16, line 15 >Change > "Derived datatypes can be created representing more elements than >can be encoded in a C int or Fortran INTEGER. MPI_GET_COUNT, >MPI_GET_ELEMENTS, and associated functions cannot properly express these >quantities. To overcome this limitation, these quatities are declared >to be INTEGER (KIND=MPI_COUNT_KIND) in Fortran. In C, one uses MPI_Count." >to > "As described above, MPI defines one type to address locations >within memory and another type to address locations within a file. >However, at times, one needs a single type that can be used to address >locations within either memory or a file. Furthermore, one needs this > > or a file, and furthermore, one needs this type to encode any value stored in a C int or Fortran INTEGER. >type to also any value stored in a C int or Fortran INTEGER. For this, >MPI defines the datatype MPI_Count in C and INTEGER >(KIND=MPI_COUNT_KIND) in Fortran." > >p 16, line 23-24 >Change > "in a variable of type C int, MPI_Aint, MPI_Offset, or Fortran INTEGER." >to > "in a variable of type int, MPI_Aint, or MPI_Offset in C and Fortran >INTEGER, INTEGER(KIND=MPI_ADDRESS_KIND), or INTEGER >(KIND=MPI_OFFSET_KIND) in Fortran." > > in C and of type INTEGER, INTEGER(KIND=MPI_ADDRESS_KIND), or INTEGER (KIND=MPI_OFFSET_KIND) in Fortran. >p 99, line 14-18 >The whole paragraph is all about the old stuff, which just confuses a >new reader. I would just drop it (or move it toward the end), and >replace it with something like: > "The following functions return the lower bound and the extent of a >datatype." > > It turns out that a statement like this one is listed below the functions. No need to list it twice, so either drop this one or drop the similar statement after the functions. >If on the otherhand we want to leave, it there are some typos (extra >period after MPI_TYPE_EXTENT and "address sized integers" probably means >MPI_ADDRESS_KIND, so we should just say "larger sized integers" or >something like that): > "MPI_TYPE_EXTENT. and also return address sized integers" --> >"MPI_TYPE_EXTENT and also return larger sized integers" >I vote to just drop and replace it, though. > >Question: What if MPI_TYPE_GET_EXTENT overflows? > >p 100, line 48 > "MPI_TYPE_GET_TRUE_EXTENT and ..." --> "The functions >MPI_TYPE_GET_TRUE_EXTENT and ..." > >p 105, line 27 > "query function MPI_GET_ELEMENTS." --> "query functions >MPI_GET_ELEMENTS or MPI_GET_ELEMENTS_X." > >p 106, line 20 > "the MPI_GET_COUNT sets the value of count to" --> "the function >sets the value of count to" > >p 106, line 20 >Move sentence about overflow up to other sentence about MPI_UNDEFINED, >and reword it a bit. > "Furthermore, if the number of basics elements is an integral number >of datatype copies but this magnitude of this value exceeds the limits >of the count parameter, then the function sets the value of count to >MPI_UNDEFINED." > > number of *basic* elements ... copies but *the* magnintude of this ... >-Adam > > > >Jeff Squyres wrote: > > > >>PDFs have been attached to the 2 MPI_Count tickets for a formal reading at the Chicago Forum meeting in 2 weeks: >> >>- General MPI_Count ticket >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >>- "W" versions of some collectives >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/269 >> >>Remember that the solution we're proposing here is the "minimal" MPI_Count approach: adding a small number of new functions that take MPI_Count arguments so that MPI can claim to fully support arbitrary-sized counts. >> >>Enjoy your light reading. :-) >> >> >> >> >> > >_______________________________________________ >mpi-forum mailing list >mpi-forum(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >

1 0

Re: [Mpi-forum] First reading: MPI_Count
by Adam T. Moody 16 Mar '11

16 Mar '11

Hi Jeff, Ugh, this whole chapter (not the count ticket itself) needs major editing. It's poorly organized and it talks about and uses deprecated concepts all over the place. I'll work with Quincey to propose a better version (along with a full set of MPI_Count datatype calls). Here are some comments for the count ticket. p 16, line 15 Change "Derived datatypes can be created representing more elements than can be encoded in a C int or Fortran INTEGER. MPI_GET_COUNT, MPI_GET_ELEMENTS, and associated functions cannot properly express these quantities. To overcome this limitation, these quatities are declared to be INTEGER (KIND=MPI_COUNT_KIND) in Fortran. In C, one uses MPI_Count." to "As described above, MPI defines one type to address locations within memory and another type to address locations within a file. However, at times, one needs a single type that can be used to address locations within either memory or a file. Furthermore, one needs this type to also any value stored in a C int or Fortran INTEGER. For this, MPI defines the datatype MPI_Count in C and INTEGER (KIND=MPI_COUNT_KIND) in Fortran." p 16, line 23-24 Change "in a variable of type C int, MPI_Aint, MPI_Offset, or Fortran INTEGER." to "in a variable of type int, MPI_Aint, or MPI_Offset in C and Fortran INTEGER, INTEGER(KIND=MPI_ADDRESS_KIND), or INTEGER (KIND=MPI_OFFSET_KIND) in Fortran." p 99, line 14-18 The whole paragraph is all about the old stuff, which just confuses a new reader. I would just drop it (or move it toward the end), and replace it with something like: "The following functions return the lower bound and the extent of a datatype." If on the otherhand we want to leave, it there are some typos (extra period after MPI_TYPE_EXTENT and "address sized integers" probably means MPI_ADDRESS_KIND, so we should just say "larger sized integers" or something like that): "MPI_TYPE_EXTENT. and also return address sized integers" --> "MPI_TYPE_EXTENT and also return larger sized integers" I vote to just drop and replace it, though. Question: What if MPI_TYPE_GET_EXTENT overflows? p 100, line 48 "MPI_TYPE_GET_TRUE_EXTENT and ..." --> "The functions MPI_TYPE_GET_TRUE_EXTENT and ..." p 105, line 27 "query function MPI_GET_ELEMENTS." --> "query functions MPI_GET_ELEMENTS or MPI_GET_ELEMENTS_X." p 106, line 20 "the MPI_GET_COUNT sets the value of count to" --> "the function sets the value of count to" p 106, line 20 Move sentence about overflow up to other sentence about MPI_UNDEFINED, and reword it a bit. "Furthermore, if the number of basics elements is an integral number of datatype copies but this magnitude of this value exceeds the limits of the count parameter, then the function sets the value of count to MPI_UNDEFINED." -Adam Jeff Squyres wrote: >PDFs have been attached to the 2 MPI_Count tickets for a formal reading at the Chicago Forum meeting in 2 weeks: > >- General MPI_Count ticket > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >- "W" versions of some collectives > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/269 > >Remember that the solution we're proposing here is the "minimal" MPI_Count approach: adding a small number of new functions that take MPI_Count arguments so that MPI can claim to fully support arbitrary-sized counts. > >Enjoy your light reading. :-) > > >

1 0