November 2013 - mpiwg-tools - mailman3.cels.anl.gov

Re: [mpiwg-tools] A minor issue of MPI_T_ERR_INVALID_ITEM
by Junchao Zhang 22 Nov '13

22 Nov '13

A tiny typo: p566, line 30: IN index number of the value ... should be IN index index of the value ... --Junchao Zhang On Fri, Nov 22, 2013 at 3:35 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Hi Junchao, > > Sorry for the delay. I've been at SC. > > In the MPI_T return code Table (P589), there are > > Return Codes for Datatype Functions: MPI_T_ENUM_* > MPI_T_ERR_INVALID_INDEX The enumeration index is invalid or has been > deleted. > MPI_T_ERR_INVALID_ITEM The item index queried is out of range (for > MPI_T_ENUM_GET_ITEM only) > > Why we used "enumeration index" here? Since in the standard, it is called > a handle. > > > I think the text could better read "enumeration item index" since the > index is for an item in the enumeration, not the enumeration itself. > > And why designed MPI_T_ERR_INVALID_ITEM specially for MPI_T_ENUM_GET_ITEM? > > > I believe the intent was to differentiate between an index that is out of > range and one that may have been deleted or invalidated for some reason, > which would give more information than just one error code. > > Do others feel this needs changing? If so, what do you think needs to > happen? Possibly this: > > In my view, there should be MPI_T_ERR_INVALID_ENUM, > MPI_T_ERR_INVALID_INDEX respectively. > > > Or another suggestion: > return MPI_T_ERR_INVALID_INDEX for indices that are invalid or deleted and > MPI_T_ERR_INVALID in the case that the index is out of range. If it's out > of range, it's a misuse of the interface, so it fits with the intent of the > new return code. > > Kathryn > > > --Junchao Zhang > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >

1 0

Re: [mpiwg-tools] A minor issue of MPI_T_ERR_INVALID_ITEM
by Kathryn Mohror 22 Nov '13

22 Nov '13

Hi Junchao, Sorry for the delay. I've been at SC. > In the MPI_T return code Table (P589), there are > > Return Codes for Datatype Functions: MPI_T_ENUM_* > MPI_T_ERR_INVALID_INDEX The enumeration index is invalid or has been deleted. > MPI_T_ERR_INVALID_ITEM The item index queried is out of range (for MPI_T_ENUM_GET_ITEM only) > > Why we used "enumeration index" here? Since in the standard, it is called a handle. I think the text could better read "enumeration item index" since the index is for an item in the enumeration, not the enumeration itself. > And why designed MPI_T_ERR_INVALID_ITEM specially for MPI_T_ENUM_GET_ITEM? I believe the intent was to differentiate between an index that is out of range and one that may have been deleted or invalidated for some reason, which would give more information than just one error code. Do others feel this needs changing? If so, what do you think needs to happen? Possibly this: > In my view, there should be MPI_T_ERR_INVALID_ENUM, MPI_T_ERR_INVALID_INDEX respectively. Or another suggestion: return MPI_T_ERR_INVALID_INDEX for indices that are invalid or deleted and MPI_T_ERR_INVALID in the case that the index is out of range. If it's out of range, it's a misuse of the interface, so it fits with the intent of the new return code. Kathryn > > --Junchao Zhang > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

A minor issue of MPI_T_ERR_INVALID_ITEM
by Junchao Zhang 15 Nov '13

15 Nov '13

In the MPI_T return code Table (P589), there are Return Codes for Datatype Functions: MPI_T_ENUM_* MPI_T_ERR_INVALID_INDEX The enumeration index is invalid or has been deleted. MPI_T_ERR_INVALID_ITEM The item index queried is out of range (for MPI_T_ENUM_GET_ITEM only) Why we used "enumeration index" here? Since in the standard, it is called a handle. And why designed MPI_T_ERR_INVALID_ITEM specially for MPI_T_ENUM_GET_ITEM? In my view, there should be MPI_T_ERR_INVALID_ENUM, MPI_T_ERR_INVALID_INDEX respectively. --Junchao Zhang

1 0

Re: [mpiwg-tools] Telecon tomorrow
by Kathryn Mohror 14 Nov '13

14 Nov '13

Hi all, The notes from the meeting are here: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2013-11-14 Also, I'm not sure when our next telecon will be, since the next one is Thanksgiving, the following one is during the Forum, and the next one is the day after Christmas. I am on vacation the 26th, but I suppose if people want to meet, we can. After that, we're looking at the 2nd week of January. If people feel that it is too long to go until Jan 9, we can try to schedule in a make-up meeting. Kathryn On Nov 13, 2013, at 1:54 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Hi all, > > As a reminder, we have our regular telecon tomorrow at 11am EST and 8am PST. The call in information is here: > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools > > Agenda items: > - Figure out what time we need at the forum meeting, tickets to vote on, etc. > - Tickets #377, #384, #383, #400 (#392) > - Discuss the "multiple device" support issue further > > Talk to you soon! > Kathryn > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] Open MPI pvar scheme
by Junchao Zhang 14 Nov '13

14 Nov '13

You can think subnames as attached strings to elements in a pvar. Whether a pvar has subnames or not is optional. So I proposed MPI_T_pvar_has_subnames() to query that. --Junchao Zhang On Thu, Nov 14, 2013 at 10:57 AM, Jeff Squyres (jsquyres) < jsquyres(a)cisco.com> wrote: > On Nov 13, 2013, at 6:13 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > > > Let me comment on the problem in your slides of last teleconf: > > Slide 2: "Problem: multiple network devices on a server – want to return > the number of sends on each device but don’t want to create a new variable > for each of them. > > Solution: have each performance variable return an array of values; > one for each underlying network device" > > > > That basically says " (an MPI implementor) creates a multi-element pvar > (i.e., pvar with count > 1)" > > > > Slide 3: "Problem: But how do you know which array slot maps to which > underlying Linux device? > > Solution: the btl_usnic_devices state performance variable." > > > > I suppose "YOU" in the problem is an MPI_T user, for example, a tool > developer. The question is distilled into "the user wants to know names of > elements in a multi-element pvar". > > We didn't talk about this on the call today. > > I don't think I agree with your above statement. It's not the *name* of > the pvar that is the issue -- a pvar already has a well-defined name. It's > what each element of a pvar value *corresponds to*. In this case, we have > a pvar with N elements in its value, and the implementation is > corresponding each element to a Linux device (and it is desirable for the > MPI_T user to know what that correspondence is). > > We therefore want a way to express that relationship: that each element > has a string corresponding to it (that is not necessarily a "name" or > "subname"). However, not all pvars have this kind of relationship. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >

1 0

Re: [mpiwg-tools] Open MPI pvar scheme
by Jeff Squyres (jsquyres) 14 Nov '13

14 Nov '13

On Nov 13, 2013, at 6:13 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > Let me comment on the problem in your slides of last teleconf: > Slide 2: "Problem: multiple network devices on a server – want to return the number of sends on each device but don’t want to create a new variable for each of them. > Solution: have each performance variable return an array of values; one for each underlying network device" > > That basically says " (an MPI implementor) creates a multi-element pvar (i.e., pvar with count > 1)" > > Slide 3: "Problem: But how do you know which array slot maps to which underlying Linux device? > Solution: the btl_usnic_devices state performance variable." > > I suppose "YOU" in the problem is an MPI_T user, for example, a tool developer. The question is distilled into "the user wants to know names of elements in a multi-element pvar". We didn't talk about this on the call today. I don't think I agree with your above statement. It's not the *name* of the pvar that is the issue -- a pvar already has a well-defined name. It's what each element of a pvar value *corresponds to*. In this case, we have a pvar with N elements in its value, and the implementation is corresponding each element to a Linux device (and it is desirable for the MPI_T user to know what that correspondence is). We therefore want a way to express that relationship: that each element has a string corresponding to it (that is not necessarily a "name" or "subname"). However, not all pvars have this kind of relationship. -- 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: [mpiwg-tools] Telecon tomorrow
by Marc-Andre Hermanns 14 Nov '13

14 Nov '13

Dear all, sorry, I let myself get thrown off by the daylight savings time changes in US and Europe again, so I will not make it in time today. :( I wanted to add some feedback to ticket #383 (the variable info consistency). I am not quite satisfied with the current wording as an advice to implementers, as it still does not give any guarantee to tools as to what to expect from a query and how to process the information. What do you think of the following idea: Let's attach a "realm" to a certain variable information. How a realm is represented would still be discussed, but for the sake of the discussion assume it is represented as an MPI_Group containing all the ranks that share the same indexing. An implementation that chooses to be super-individualistic and promise nothing can do so by using the "self-group" as the realm for any variable information. An implementation that wants to help a tool to unify information automatically, can use larger realms up to the point where every information is in a single global realm. Example: The DEEP project [1], which investigates a mixed-network accelerator cluster having a pure-infiniband, a pure-extoll part, and a mixed-infiniband-extoll part could choose to create three different realms, guaranteeing that the information within each realm matches across processes. This idea is very rough-cut, but would something along this line work for everyone? It should still allow implementations not to give any guarantee, but at least enables tools to query the level of consistency given by an implementation and complain accordingly. What are your ideas on this? Cheers, Marc-Andre [1] http://www.deep-project.eu/ On 13.11.13 22:54, Kathryn Mohror wrote: > Hi all, > > As a reminder, we have our regular telecon tomorrow at 11am EST and 8am > PST. The call in information is here: > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools > > Agenda items: > - Figure out what time we need at the forum meeting, tickets to vote > on, etc. > - Tickets #377, #384, #383, #400 (#392) > - Discuss the "multiple device" support issue further > > Talk to you soon! > Kathryn > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov > <mailto:[email protected]>, http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > -- Marc-Andre Hermanns German Research School for Simulation Sciences GmbH c/o Laboratory for Parallel Programming 52062 Aachen | Germany Tel +49 241 80 99753 Fax +49 241 80 6 99753 Web www.grs-sim.de Members: Forschungszentrum Jülich GmbH | RWTH Aachen University Registered in the commercial register of the local court of Düren (Amtsgericht Düren) under registration number HRB 5268 Registered office: Jülich Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt

1 0

Re: [mpiwg-tools] Open MPI pvar scheme
by Junchao Zhang 13 Nov '13

13 Nov '13

Let me comment on the problem in your slides of last teleconf: Slide 2: "Problem: multiple network devices on a server – want to return the number of sends on each device but don’t want to create a new variable for each of them. Solution: have each performance variable return an array of values; one for each underlying network device" That basically says " (an MPI implementor) creates a multi-element pvar (i.e., pvar with count > 1)" Slide 3: "Problem: But how do you know which array slot maps to which underlying Linux device? Solution: the btl_usnic_devices state performance variable." I suppose "YOU" in the problem is an MPI_T user, for example, a tool developer. The question is distilled into "the user wants to know names of elements in a multi-element pvar". My solution is to provide the user with a new routine MPI_T_pvar_get_subnames. Whether these names are shared or duplicated between pvars, the user doesn't need to know. It is an MPI implementation issue. We already have name for pvar. That is why I use "subnames" for names of elements in a such a pvar. Is my understanding of the problem correct? --Junchao Zhang On Wed, Nov 13, 2013 at 4:17 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com > wrote: > I'm afraid I didn't understand your prior proposal; I hoped there would be > more explanation. > > Perhaps you can make up several slides to explain what you're proposing > with some pictures and diagrams for tomorrow. E.g., what is your *exact* > definition of a "subname"? And how would I apply a set of common subnames > to N different pvars (hopefully without replicating them N times)? > > > On Nov 13, 2013, at 5:02 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > > > After reading mails in this thread, it seems we just want to get names > of elements in a pvar, right? > > So, why do not provide this functionality directly. > > // Return true or false in has_subnames. > > MPI_T_pvar_has_subnames(session, handle, int has_subnames); > > // If has_subnames, use this function to get their names > > MPI_T_pvar_get_subnames(session, handle, char * subnames[], int > lens[]); // Very like the newly proposed MPI_T_pvar_read_str() > > > > --Junchao Zhang > > > > On Tue, Nov 12, 2013 at 4:09 PM, Schulz, Martin <schulzm(a)llnl.gov> > wrote: > > > > On Nov 12, 2013, at 12:51 PM, "Jeff Squyres (jsquyres)" < > jsquyres(a)cisco.com> > > wrote: > > > > > On Nov 11, 2013, at 7:03 PM, "Schulz, Martin" <schulzm(a)llnl.gov> > wrote: > > > > > >>>> I think it would be better to programmatically express such > relationships -- i.e., something new for MPI-4. > > >> > > >> I agree with that, but I see it more as an MPI 3.1 feature. Is it > really a major concept? > > > > > > I thought it was "more" than a minor/bug fix concept... and therefore > should wait until 4. > > > > We need to finally discuss and decide that (as the forum) - this will > definitely be on the agenda in December. > > > > >>> Er... I don't understand. Why can't the enum strings change? I > think they can change at any time. > > >> > > >> So that's a good question - I was assuming (at least that's how I > always thought about it) that the same rules as for variables and all their > metadata apply here - once read, a description cannot change and an > enumeration type can worst thing grow. It is correct, though, that we > didn't specify that explicitly - perhaps we need to do that. The only text > that comes close is "The second datatype class, enumeration datatypes, > describes variables with a fixed set of discrete values.". > > > > > > Mmm. Yes. This *implies* that they don't change, but one could argue > different meanings of "fixed set". > > > > I know, this is ambiguous. > > > > > > > >> Having strings change underneath would be a real problem for the > string interface, since it makes the assumption that you can run queries > against a string more than once and get the same string. > > > > > > It sounds like you are introducing a new requirement, then: you want > non-mutable strings, but the ability to have things change over time (e.g., > new NICs added or old NICs dropped). > > > > Well, I think we have two separate issues here: > > - Should strings be allowed to change? In particular, should we allow > enumerations to change on the fly? I think the answer to this should be no, > since this would create race conditions and it would prevent tools from > caching any data (that's why we did it for the variable metadata and for > the types it seems even more relevant) > > - Do we need a mechanism to describe changing variable arrays? This is > more a requirement question - how is this in your case? Will you support > changing number of NICs and how are you planning on doing that? > > > > > > > >>> I think what you might be saying is that the *count* on a handle > can't change -- right? I.e., MPI_T currently has no way of saying, "There > were N values when you called pvar_handle_alloc() for this pvar, but now > this pvar has M values." > > >> > > >> Yes, but the count can change when you get a new handle. > > > > > > That would be fairly hellish for an implementation: session/handle X > has N values, but simultaneously, session/handle Y of the same pvar -- > which just happened to be created after session/handle X -- has M values. > > > > > > Meaning: the implementation has to track two entirely different > views/counts of the same pvar. > > > > Well, wouldn't that be up to the implementation? If it doesn't make > sense for a particular case, then an MPI can always return the same count. > I agree, if an MPI does do it that way, it won't be easy. > > > > > > > >> Yes, that's what I meant with "doesn't have to be at the moment" - > any variable that has the potential to have a count that is not 1 is > affected. > > > > > > ...which is *any* variable, right? > > > > Yes - what I meant was that if there is a variable that a particular MPI > implementation always decides to return 1 for, then you will probably never > need a matching enumeration variable. However, just because it returns 1 > once, it doesn't mean that it is guaranteed that it will stay that way for > the rest of the run or during the next run. Hence, matching enumeration > variables make sense even for variables that have a count of 1. > > > > Martin > > > > > > > > > > -- > > > Jeff Squyres > > > jsquyres(a)cisco.com > > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > > > > ________________________________________________________________________ > > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > > > > _______________________________________________ > > mpiwg-tools mailing list > > mpiwg-tools(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > > _______________________________________________ > > mpiwg-tools mailing list > > mpiwg-tools(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >

1 0

Re: [mpiwg-tools] Open MPI pvar scheme
by Jeff Squyres (jsquyres) 13 Nov '13

13 Nov '13

I'm afraid I didn't understand your prior proposal; I hoped there would be more explanation. Perhaps you can make up several slides to explain what you're proposing with some pictures and diagrams for tomorrow. E.g., what is your *exact* definition of a "subname"? And how would I apply a set of common subnames to N different pvars (hopefully without replicating them N times)? On Nov 13, 2013, at 5:02 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > After reading mails in this thread, it seems we just want to get names of elements in a pvar, right? > So, why do not provide this functionality directly. > // Return true or false in has_subnames. > MPI_T_pvar_has_subnames(session, handle, int has_subnames); > // If has_subnames, use this function to get their names > MPI_T_pvar_get_subnames(session, handle, char * subnames[], int lens[]); // Very like the newly proposed MPI_T_pvar_read_str() > > --Junchao Zhang > > On Tue, Nov 12, 2013 at 4:09 PM, Schulz, Martin <schulzm(a)llnl.gov> wrote: > > On Nov 12, 2013, at 12:51 PM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > wrote: > > > On Nov 11, 2013, at 7:03 PM, "Schulz, Martin" <schulzm(a)llnl.gov> wrote: > > > >>>> I think it would be better to programmatically express such relationships -- i.e., something new for MPI-4. > >> > >> I agree with that, but I see it more as an MPI 3.1 feature. Is it really a major concept? > > > > I thought it was "more" than a minor/bug fix concept... and therefore should wait until 4. > > We need to finally discuss and decide that (as the forum) - this will definitely be on the agenda in December. > > >>> Er... I don't understand. Why can't the enum strings change? I think they can change at any time. > >> > >> So that's a good question - I was assuming (at least that's how I always thought about it) that the same rules as for variables and all their metadata apply here - once read, a description cannot change and an enumeration type can worst thing grow. It is correct, though, that we didn't specify that explicitly - perhaps we need to do that. The only text that comes close is "The second datatype class, enumeration datatypes, describes variables with a fixed set of discrete values.". > > > > Mmm. Yes. This *implies* that they don't change, but one could argue different meanings of "fixed set". > > I know, this is ambiguous. > > > > >> Having strings change underneath would be a real problem for the string interface, since it makes the assumption that you can run queries against a string more than once and get the same string. > > > > It sounds like you are introducing a new requirement, then: you want non-mutable strings, but the ability to have things change over time (e.g., new NICs added or old NICs dropped). > > Well, I think we have two separate issues here: > - Should strings be allowed to change? In particular, should we allow enumerations to change on the fly? I think the answer to this should be no, since this would create race conditions and it would prevent tools from caching any data (that's why we did it for the variable metadata and for the types it seems even more relevant) > - Do we need a mechanism to describe changing variable arrays? This is more a requirement question - how is this in your case? Will you support changing number of NICs and how are you planning on doing that? > > > > >>> I think what you might be saying is that the *count* on a handle can't change -- right? I.e., MPI_T currently has no way of saying, "There were N values when you called pvar_handle_alloc() for this pvar, but now this pvar has M values." > >> > >> Yes, but the count can change when you get a new handle. > > > > That would be fairly hellish for an implementation: session/handle X has N values, but simultaneously, session/handle Y of the same pvar -- which just happened to be created after session/handle X -- has M values. > > > > Meaning: the implementation has to track two entirely different views/counts of the same pvar. > > Well, wouldn't that be up to the implementation? If it doesn't make sense for a particular case, then an MPI can always return the same count. I agree, if an MPI does do it that way, it won't be easy. > > > > >> Yes, that's what I meant with "doesn't have to be at the moment" - any variable that has the potential to have a count that is not 1 is affected. > > > > ...which is *any* variable, right? > > Yes - what I meant was that if there is a variable that a particular MPI implementation always decides to return 1 for, then you will probably never need a matching enumeration variable. However, just because it returns 1 once, it doesn't mean that it is guaranteed that it will stay that way for the rest of the run or during the next run. Hence, matching enumeration variables make sense even for variables that have a count of 1. > > Martin > > > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com > > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- 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: [mpiwg-tools] Open MPI pvar scheme
by Junchao Zhang 13 Nov '13

13 Nov '13

After reading mails in this thread, it seems we just want to get names of elements in a pvar, right? So, why do not provide this functionality directly. // Return true or false in has_subnames. MPI_T_pvar_has_subnames(session, handle, int has_subnames); // If has_subnames, use this function to get their names MPI_T_pvar_get_subnames(session, handle, char * subnames[], int lens[]); // Very like the newly proposed MPI_T_pvar_read_str() --Junchao Zhang On Tue, Nov 12, 2013 at 4:09 PM, Schulz, Martin <schulzm(a)llnl.gov> wrote: > > On Nov 12, 2013, at 12:51 PM, "Jeff Squyres (jsquyres)" < > jsquyres(a)cisco.com> > wrote: > > > On Nov 11, 2013, at 7:03 PM, "Schulz, Martin" <schulzm(a)llnl.gov> wrote: > > > >>>> I think it would be better to programmatically express such > relationships -- i.e., something new for MPI-4. > >> > >> I agree with that, but I see it more as an MPI 3.1 feature. Is it > really a major concept? > > > > I thought it was "more" than a minor/bug fix concept... and therefore > should wait until 4. > > We need to finally discuss and decide that (as the forum) - this will > definitely be on the agenda in December. > > >>> Er... I don't understand. Why can't the enum strings change? I think > they can change at any time. > >> > >> So that's a good question - I was assuming (at least that's how I > always thought about it) that the same rules as for variables and all their > metadata apply here - once read, a description cannot change and an > enumeration type can worst thing grow. It is correct, though, that we > didn't specify that explicitly - perhaps we need to do that. The only text > that comes close is "The second datatype class, enumeration datatypes, > describes variables with a fixed set of discrete values.". > > > > Mmm. Yes. This *implies* that they don't change, but one could argue > different meanings of "fixed set". > > I know, this is ambiguous. > > > > >> Having strings change underneath would be a real problem for the string > interface, since it makes the assumption that you can run queries against a > string more than once and get the same string. > > > > It sounds like you are introducing a new requirement, then: you want > non-mutable strings, but the ability to have things change over time (e.g., > new NICs added or old NICs dropped). > > Well, I think we have two separate issues here: > - Should strings be allowed to change? In particular, should we allow > enumerations to change on the fly? I think the answer to this should be no, > since this would create race conditions and it would prevent tools from > caching any data (that's why we did it for the variable metadata and for > the types it seems even more relevant) > - Do we need a mechanism to describe changing variable arrays? This is > more a requirement question - how is this in your case? Will you support > changing number of NICs and how are you planning on doing that? > > > > >>> I think what you might be saying is that the *count* on a handle can't > change -- right? I.e., MPI_T currently has no way of saying, "There were N > values when you called pvar_handle_alloc() for this pvar, but now this pvar > has M values." > >> > >> Yes, but the count can change when you get a new handle. > > > > That would be fairly hellish for an implementation: session/handle X has > N values, but simultaneously, session/handle Y of the same pvar -- which > just happened to be created after session/handle X -- has M values. > > > > Meaning: the implementation has to track two entirely different > views/counts of the same pvar. > > Well, wouldn't that be up to the implementation? If it doesn't make sense > for a particular case, then an MPI can always return the same count. I > agree, if an MPI does do it that way, it won't be easy. > > > > >> Yes, that's what I meant with "doesn't have to be at the moment" - any > variable that has the potential to have a count that is not 1 is affected. > > > > ...which is *any* variable, right? > > Yes - what I meant was that if there is a variable that a particular MPI > implementation always decides to return 1 for, then you will probably never > need a matching enumeration variable. However, just because it returns 1 > once, it doesn't mean that it is guaranteed that it will stay that way for > the rest of the run or during the next run. Hence, matching enumeration > variables make sense even for variables that have a count of 1. > > Martin > > > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >

1 0