<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi all,<div><br></div><div>Our next tools WG meeting is (as usual) on Monday 8/23 (tomorrow) at 8am PDT, </div><div>11am EDT, 5pm MSZ. Jeff created a Webex session for us, which is linked on the</div><div>tools Wiki. It is:</div><div><br></div><div><a class="ext-link" href="https://cisco.webex.com/ciscosales/j.php?ED=145066572&UID=0&PW=NMjcyNzAwZmU2&RT=MiMxMQ%3D%3D">https://cisco.webex.com/ciscosales/j.php?ED=145066572&UID=0&PW=NMjcyNzAwZmU2&RT=MiMxMQ%3D%3D</a></div><div>Password: tools</div><div><br></div><div>We have two main item for the agenda: MPIR and MPIT.</div><div><br></div><div>MPIR: John requested some time to finish the discussion on the MPIR document before</div><div>we turn the document into a standard compliant Latex document and give it for to the</div><div>MPI forum forum for review (has to happen by the end of next week).</div><div><br></div><div>MPIT: I recently gave a presentation on MPIT to the tools community and I would like to</div><div>discuss the feedback from that meeting and its impact on the MPIT proposal. More detail</div><div>on this are below.</div><div><br></div><div>Talk to you tomorrow / Monday,</div><div><br></div><div>Martin</div><div><br></div><div><br></div><div><br></div><div>Feedback from the tools community on MPIT (based on CScADS discussions):</div><div>(for those of you who were at the CScADS workshop, please feel free to add)</div><div><br></div><div>Collection of use cases</div><div><span class="Apple-tab-span" style="white-space:pre">    </span>Current ideas in MPIT seem to match those use cases very well</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>High/Low watermarks seen as quite useful</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>Identification of exhausted resources important</div><div><br></div><div>Naming</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Several name changes suggested</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>configuration variables -> control variables (as in OpenMP)</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>Prefixes:</div><div><span class="Apple-tab-span" style="white-space:pre">            </span>MPIT_CTRLVARS_...</div><div><span class="Apple-tab-span" style="white-space:pre">            </span>MPIT_PERFVARS_...</div><div><br></div><div>Verbosity levels</div><div><span class="Apple-tab-span" style="white-space:pre">    </span>Why restrict verbosity from 1 to 5?</div><div><span class="Apple-tab-span" style="white-space:pre">  </span>Allow a query for the max. verbosity N and then allow levels 1-N</div><div><br></div><div>Initialization</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>Suggestion to remove IsInitialized and IsFinalized</div><div><span class="Apple-tab-span" style="white-space:pre">   </span>(not useful if we can initialize MPIT multiple times)</div><div><br></div><div>Bias towards adding Fortran routines</div><div><span class="Apple-tab-span" style="white-space:pre">    </span>Need more feedback from the Fortran gurus in the MPI forum</div><div><br></div><div><div>Control variables</div></div><div><span class="Apple-tab-span" style="white-space:pre">   </span>Very strong wish to allow the setting of control variables</div><div><span class="Apple-tab-span" style="white-space:pre">   </span>In particular autotuning community is very interested and promised to</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>write up several concrete use cases</div><div><span class="Apple-tab-span" style="white-space:pre">  </span>How to deal with setting the variables from multiple tools</div><div><span class="Apple-tab-span" style="white-space:pre">           </span>a) provide lock/unlock routines</div><div><span class="Apple-tab-span" style="white-space:pre">              </span>b) allow one tool to Initialize MPIT exclusively in MPIT_Init</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>c) Do nothing and leave races up to tools/users</div><div><span class="Apple-tab-span" style="white-space:pre">      </span>How to deal with synchronizing variables</div><div><span class="Apple-tab-span" style="white-space:pre">             </span>Provide additional information during query:</div><div><span class="Apple-tab-span" style="white-space:pre">                 </span>readonly - can never be set</div><div><span class="Apple-tab-span" style="white-space:pre">                  </span>sync/nosync - shows whether a variables is synchronizing or not</div><div><span class="Apple-tab-span" style="white-space:pre">                      </span>communicator - setting a synchronizing variables requires a global</div><div><span class="Apple-tab-span" style="white-space:pre">                           </span>operation on this communicator </div><div><span class="Apple-tab-span" style="white-space:pre">                         </span>(can be MPI_COMM_SELF for nosync variables)</div><div><span class="Apple-tab-span" style="white-space:pre">          </span>Set routine takes communicator as argument</div><div><span class="Apple-tab-span" style="white-space:pre">                   </span>Must be called by all members of the communicator</div><div><br></div><div>Extensibility</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>Very strong wish to have the option to extend this interface</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Tools should have the ability to provide new variables</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>(this was brought up by several tools groups for various needs)</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">     </span>Seen as essential (not just for Extensibility): Profiling routines for MPIT</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Would like to see a different iterator concept:</div><div><span class="Apple-tab-span" style="white-space:pre">              </span>change from iterators to a list of variables with an integer index</div><div><span class="Apple-tab-span" style="white-space:pre">           </span>(this fixes the type of the iterator)</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>Query the number of variables and then provide query routines to ask</div><div><span class="Apple-tab-span" style="white-space:pre">                 </span>for more information on each variable</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>Restrictions: variables can not be removed or reordered, just added</div><div><span class="Apple-tab-span" style="white-space:pre">          </span></div><div><span class="Apple-tab-span" style="white-space:pre"><span class="Apple-tab-span" style="white-space:pre">      </span>H</span>ow to return query information:</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>Return a struct instead of a list of arguments</div><div><span class="Apple-tab-span" style="white-space:pre">               </span>Cleaner ways to integrate new information in future versions</div><div><span class="Apple-tab-span" style="white-space:pre">         </span>Need separate MPIT version constant to guard extensions</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">     </span>Ideally: would like to give MPI an address for a variable to watch and MPI</div><div><span class="Apple-tab-span" style="white-space:pre">           </span>would then integrate this variable into the MPIT variables</div><div><span class="Apple-tab-span" style="white-space:pre">           </span>-> easy extension for new variables by external tools through same API</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">   </span>Alternatively: tools can hide this in an PMPIT layer, but then need additional</div><div><span class="Apple-tab-span" style="white-space:pre">               </span>mechanisms to allocate "dummy" handles to avoid duplicating the handle space</div><div><br></div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">             </span></div><div><br></div><div><br></div><div><br></div><div><br><div apple-content-edited="true"> <div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>________________________________________________________________________</div><div>Martin Schulz, schulzm@llnl.gov, <a href="http://people.llnl.gov/schulzm">http://people.llnl.gov/schulzm</a></div><div>CASC @ Lawrence Livermore National Laboratory, Livermore, USA</div><div><br></div></div></div><br class="Apple-interchange-newline"> </div><br></div></body></html>