<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">True, but not the original goal, and the current design makes the common case *very* easy for users. A more general but equally easy to use interface would be great, of course.<div>Bill</div><div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; 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-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="font-size: 12px; ">William Gropp</div><div style="font-size: 12px; ">Director, Parallel Computing Institute</div><div style="font-size: 12px; ">Deputy Director for Research</div><div style="font-size: 12px; ">Institute for Advanced Computing Applications and Technologies</div></div></div></span><span class="Apple-style-span" style="font-size: 12px; ">Thomas M. Siebel Chair in Computer Science</span><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="font-size: 12px; ">University of Illinois Urbana-Champaign</div></div><div><br></div></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br><div><div>On Apr 16, 2013, at 12:39 PM, Jeff Squyres (jsquyres) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>But without a portable run-time way to query what tool is being used, it makes it darn difficult to write portable MPI applications that want to tune for multiple different tools.<br><br><br>On Apr 16, 2013, at 9:56 AM, William Gropp <<a href="mailto:wgropp@illinois.edu">wgropp@illinois.edu</a>> wrote:<br><br><blockquote type="cite">The idea was not portability between different tools, but between linking with *a* tool that uses the profiling interface, and without that tool. The varargs interface allows the user to customize for *one* tool, while not needing to change the code to link without the tool. I personally find this sufficient for most needs. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Bill<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">William Gropp<br></blockquote><blockquote type="cite">Director, Parallel Computing Institute<br></blockquote><blockquote type="cite">Deputy Director for Research<br></blockquote><blockquote type="cite">Institute for Advanced Computing Applications and Technologies<br></blockquote><blockquote type="cite">Thomas M. Siebel Chair in Computer Science<br></blockquote><blockquote type="cite">University of Illinois Urbana-Champaign<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Apr 16, 2013, at 10:56 AM, Marc-Andre Hermanns wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Hi Martin,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 4/15/13 4:38 PM, Schulz, Martin wrote:<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">As a first simple approach, this could be done with<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">MPI_Pcontrol_new(MPI_Info info)<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The original question seemed specific to the Fortran interface for MPI_PCONTROL. Would it be possible to keep the C interface, either as is or modified as suggested above, but delete the Fortran interface for this routine? That solves the immediate issue.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I would argue that the few people who use this routine are "expert users" who would have little trouble writing their own MY_PCONTROL, written in C but callable from Fortran that had whatever interoperable arguments were desired, and internally called the C MPI_Pcontrol function.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Or not even bother with MPI_Pcontrol, because it's less hassle to<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">implement the whole thing from scratch and provide their own interfaces.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I agree - this isn't likely to impact more than 0.1% of users, who are<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">quite capable of resolving any difficulties.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I don't think that's quite true - Pcontrol is useful in many cases<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">and is used by profilers (that are advertised as easy to use). It is<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">certainly a bit more advanced usage, but in many cases we tell users<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">where to put it, so they can run their code and get data, but it has<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">to be easy for them to add it or they won't do it. Having to go<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">through C in Fortran codes is not really a workable solution in this<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">case. That's also how we ran into the problem that we are discussing:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">we had a user new to performance analysis during a tutorial and he<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">wanted to profile a particular snapshot and so we asked him to add<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the calls. Due to the ierr issue, this crashed the code.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">But where did it crash? In the MPI library or in the profiler?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The only way to make only having a C call work would be a separate<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">library, but then that defeats the purpose of adding something that<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">can just stay in the code without having to link to special libraries<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">(which was the main reason for adding MPI_Pcontrol). MPI_Pcontrol is<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">(unlike MPI_T) intended to be used in the application code and hence<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">should have bindings in all languages supported by MPI.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">What I still don't understand about Pcontrol is that the varargs make it inherently non-portable, or not? I don't mean the "portablility" between C and Fortran, I mean: If the call to MPI_Pcontrol takes anything else than the initial 'level' it will very likely crash with the use of another tool that expects different parameters. If the user has to modify the code for using a different tool to use a feature, I would argue against its portability.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I think the only way of handling this portably would be if the call itself, took a handle-like identifier, and the tool itself would implement another call that creates the opaque object behind it.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Something along the lines of:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">int MPI_Pcontrol_create(MPI_Pctrl* handle);<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">int MPI_Pcontrol_free(MPI_Pctrl* handle);<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The idea is that the Profiling tool would not call PMPI_Pcontrol_create but just create the a structure, do its own book-keeping and return the handle.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Then Pcontrol takes this handle (which can transport anything the profiling tool would expect)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">int MPI_Pcontrol(int level, MPI_Pctrl handle);<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and maybe something like:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">int MPI_Pcontrol_set(MPI_Pctrl handle, MPI_Info info);<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If the tool does not understand some of the infos (because they are meant for a different tool) it ignores it and should use some form of a consistent default state.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">But I don't know if the latter would really improve over your initial proposal with the info object as a parameter to the Pcontrol call itself, as I don't have any experience with how often one would have to modify the handle. If you have to modify the handle with every call, then you don't gain anything.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cheers,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Marc-Andre<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-- <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Marc-Andre Hermanns<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">German Research School for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Simulation Sciences GmbH<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">c/o Laboratory for Parallel Programming<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">52062 Aachen | Germany<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Tel +49 241 80 99753<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Fax +49 241 80 6 99753<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Web <a href="http://www.grs-sim.de">www.grs-sim.de</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Members: Forschungszentrum Jülich GmbH | RWTH Aachen University<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Registered in the commercial register of the local court of<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Düren (Amtsgericht Düren) under registration number HRB 5268<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Registered office: Jülich<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Mpi3-tools mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:Mpi3-tools@lists.mpi-forum.org">Mpi3-tools@lists.mpi-forum.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><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></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Mpi3-tools mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Mpi3-tools@lists.mpi-forum.org">Mpi3-tools@lists.mpi-forum.org</a><br></blockquote><blockquote type="cite"><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: http://www.cisco.com/web/about/doing_business/legal/cri/<br><br><br>_______________________________________________<br>Mpi3-tools mailing list<br>Mpi3-tools@lists.mpi-forum.org<br>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools<br></div></blockquote></div><br></div></body></html>