<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi all,<div><br></div><div>Here is the next version of the look up by name function for discussion on tomorrow's call:</div><div><br></div><div><div style="margin: 0px; font-size: 13px; ">MPI_T_CVAR_GET_INDEX(name, name_len, cvar_index)</div><div style="margin: 0px; font-size: 13px; min-height: 16px; "><br></div><div style="margin: 0px; font-size: 13px; ">IN name</div><div style="margin: 0px; font-size: 13px; ">IN name_len</div><div style="margin: 0px; font-size: 13px; ">OUT cvar_index</div><div style="margin: 0px; font-size: 13px; min-height: 16px; "><br></div><div style="margin: 0px; font-size: 13px; ">MPI_T_CVAR_GET_INDEX is a convenience function for retrieving the index of a control variable given a known variable name. The name and name_len parameters are provided by the caller, and cvar_index is returned by the MPI implementation. The name parameter is a C style NULL terminated string. The name_len parameter is the length of name plus one for the NULL termination character.</div><div style="margin: 0px; font-size: 13px; min-height: 16px; "><br></div><div style="margin: 0px; font-size: 13px; ">This routine returns MPI_SUCCESS on success and returns MPI_T_ERR_INVALID_NAME if name does not match the name of any control variable provided by the implementation at the time of the call.</div><div style="margin: 0px; font-size: 13px; min-height: 16px; "><br></div><div style="margin: 0px; font-size: 13px; ">Rationale:</div><div style="margin: 0px; font-size: 13px; ">This routine is provided to enable fast retrieval of control variables by a tool, assuming it knows the name of the variable it is looking for. The number of variables exposed by the implementation can change over time, so it is not possible for the tool to simply iterate over the list of variables once at initialization. Although using MPI implementation specific variable names is not portable across MPI implementations, tool developers may choose to take this route for lower overhead at runtime because the tool won't have to loop over the entire set of variables to find a specific one. </div><div style="margin: 0px; font-size: 13px; min-height: 16px; "><br></div><div style="margin: 0px; font-size: 13px; ">MPI_T_PVAR_GET_INDEX</div><div style="margin: 0px; font-size: 13px; ">similar</div></div><div><br></div><div><br></div><div>Kathryn</div><div><br></div><div><br><div><div>On May 2, 2013, at 10:16 AM, Kathryn Mohror <<a href="mailto:kathryn@llnl.gov">kathryn@llnl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Bronis, all,<div><br></div><div>We discussed this on the WG call today. I put the notes from the discussion on the wiki page. The gist of the conversation was that yes, it is a convenience function, but it may be worth having. The reason is that a tool can't simply iterate over the variables once and be done with it. The number of variables can increase at runtime, so a tool may have to iterate more than once. </div><div><br></div><div>We settled on moving forward with a version of the routine that doesn't duplicate "get_info" but returns only the index and seeing how it plays out. </div><div><br></div><div>Kathryn</div><div><br><div><div>On May 2, 2013, at 6:19 AM, Bronis R. de Supinski <<a href="mailto:bronis@llnl.gov">bronis@llnl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br>I agree with Jeff that this request is a convenience function.<br>Not only do I think he is right about it not needing to be<br>performant and that an application could clearly do it<br>itself but any more efficient implementation could be replicated<br>at the application layer. For example, the tree-based approach<br>could be done with one pass over the list that builds the tree.<br><br>On Thu, 2 May 2013, Jeff Squyres (jsquyres) wrote:<br><br><blockquote type="cite">On May 1, 2013, at 1:06 AM, "Schulz, Martin" <<a href="mailto:schulzm@llnl.gov">schulzm@llnl.gov</a>> wrote:<br><br><blockquote type="cite"><blockquote type="cite">Is this just a convenience function?<br></blockquote><br>An implementation could store all variables in a tree (or some other more efficient structure) eliminating the need for a loop in favor of a lower complexity lookup algorithm. How severe this problem is, is a different question.<br></blockquote><br>I don't think that efficiency is the issue here -- even for an MPI implementation with thousands of cvars, a loop over them would take microseconds, at most. More specifically: I was not under the impression that cvar access needed to be performant.<br><br>I guess my point is that: regardless of mechanism, this functionality can definitely be implemented in the user application with the current MPIT APIs. Moving this functionality to *inside* MPIT is a convenience.<br><br>I'm not saying this is a good or bad idea -- I'm just making sure we all understand what is being asked. :-)<br><br><blockquote type="cite">If we want to go for such a function, I wonder, though, if we should return all the arguments from GET_INFO or just the index (that you can then use get the rest of the information). This would could both keep the document (we are mentioning the GET_INFO functions a lot) and the implementations (only one pair of routines with such complex prototypes) simpler.<br><br>Martin<br><br><br><blockquote type="cite"><br><br>On Apr 30, 2013, at 2:39 PM, Kathryn Mohror <<a href="mailto:kathryn@llnl.gov">kathryn@llnl.gov</a>> wrote:<br><br><blockquote type="cite">Hi all,<br><br>I've started to work on 3.1 items. The first one is to allow the look up of variables by name instead of having to iterate through all variables until you find the one you want (assuming you know the name in advance). What do people think of this for supporting that functionality:<br><br>MPI_T_CVAR_GET_INFO_NAMED<br><span class="Apple-tab-span" style="white-space:pre"> </span>IN <span class="Apple-tab-span" style="white-space:pre"> </span> name<br><span class="Apple-tab-span" style="white-space:pre"> </span>OUT cvar_index<br><span class="Apple-tab-span" style="white-space:pre"> </span>OUT<span class="Apple-tab-span" style="white-space:pre"> </span> verbosity<br> <span class="Apple-tab-span" style="white-space:pre"> </span>OUT datatype<br> OUT enumtype<br> <span class="Apple-tab-span" style="white-space:pre"> </span>OUT<span class="Apple-tab-span" style="white-space:pre"> </span> desc<br> INOUT desc_len<br> OUT bind<br> OUT scope<br><br>MPI_T_CVAR_GET_INFO_NAMED behaves similarly to MPI_T_CVAR_GET_INFO except that the lookup is done by control variable name instead of its index. All restrictions and requirements for MPI_T_CVAR_GET_INFO are the same for MPI_GET_CVAR_INFO_NAMED except that the cvar_index is now returned from the function, and name is an input.<br><br><br>Then define MPI_T_PVAR_GET_INFO_NAMED in a similar fashion.<br><br>Thoughts? Objections?<br><br>Kathryn<br><br><br>______________________________________________________________<br>Kathryn Mohror, <a href="mailto:kathryn@llnl.gov">kathryn@llnl.gov</a>, <a href="http://people.llnl.gov/mohror1">http://people.llnl.gov/mohror1</a><br>CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA<br><br><br><br><br>_______________________________________________<br>Mpi3-tools mailing list<br><a href="mailto:Mpi3-tools@lists.mpi-forum.org">Mpi3-tools@lists.mpi-forum.org</a><br><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools</a><br></blockquote><br><br>--<br>Jeff Squyres<br><a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>For corporate legal information go to: <a href="http://www.cisco.com/web/about/doing_business/legal/cri/">http://www.cisco.com/web/about/doing_business/legal/cri/</a><br><br><br>_______________________________________________<br>Mpi3-tools mailing list<br><a href="mailto:Mpi3-tools@lists.mpi-forum.org">Mpi3-tools@lists.mpi-forum.org</a><br>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools<br></blockquote><br>________________________________________________________________________<br>Martin Schulz, <a href="mailto:schulzm@llnl.gov">schulzm@llnl.gov</a>, <a href="http://people.llnl.gov/schulzm">http://people.llnl.gov/schulzm</a><br>CASC @ Lawrence Livermore National Laboratory, Livermore, USA<br><br><br><br><br>_______________________________________________<br>Mpi3-tools mailing list<br><a href="mailto:Mpi3-tools@lists.mpi-forum.org">Mpi3-tools@lists.mpi-forum.org</a><br><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools</a><br></blockquote><br><br>-- <br>Jeff Squyres<br><a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>For corporate legal information go to: <a href="http://www.cisco.com/web/about/doing_business/legal/cri/">http://www.cisco.com/web/about/doing_business/legal/cri/</a><br><br><br>_______________________________________________<br>Mpi3-tools mailing list<br><a href="mailto:Mpi3-tools@lists.mpi-forum.org">Mpi3-tools@lists.mpi-forum.org</a><br>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools<br><br></blockquote>_______________________________________________<br>Mpi3-tools mailing list<br><a href="mailto:Mpi3-tools@lists.mpi-forum.org">Mpi3-tools@lists.mpi-forum.org</a><br><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools</a><br></blockquote></div><br><div>
<div style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>______________________________________________________________<br>Kathryn Mohror, <a href="mailto:kathryn@llnl.gov">kathryn@llnl.gov</a>, <a href="http://people.llnl.gov/mohror1">http://people.llnl.gov/mohror1</a><br>CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA</div><div><br></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br></div></div></blockquote></div><br><div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>______________________________________________________________<br>Kathryn Mohror, <a href="mailto:kathryn@llnl.gov">kathryn@llnl.gov</a>, <a href="http://people.llnl.gov/mohror1">http://people.llnl.gov/mohror1</a><br>CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA</div><div><br></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br></div></body></html>