[mpiwg-tools] Per the QMPI/PMPI+1/whatever discussion yesterday

[Bland, Wesley B.]

> On Dec 9, 2014, at 5:31 AM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:
> 
> This morning, I have a bunch of follow-on thoughts to the QPMI/PMPI+1/whatever tools WG face-to-face discussion yesterday.  We were all getting tired at the end, and I don't think we documented everything well.  Here are my thoughts this morning, in no particular order:
> 
> 1. New names: QMPI_Tool_add / QMPI_Tool_get.  In general, using the "QMPI_" prefix should be sufficient for distinguishing any new functions we create here from both the PMPI_ world and from the MPI_T_ world.  E.g., even though the 2 names I propose here include the word "tool", I think the QMPI_ prefix is sufficient to distinguish them from the MPI_T_ tool genre.

Q* seems fine to me. I don’t really care a lot about that end of the name, but I think perhaps the QMPI_Tool_get name isn’t right anymore since we’ve changed the definition of the function from the beginning of the discussion. Now that it’s aimed at providing the tool(s) that is(are) initialized after MPI_Init, perhaps it should be something like QMPI_Tool_get_initialized().
> 
> 2. Things we didn't document yesterday:
> 
> - Need to decide a free-memory model for QMPI_Tool_get (i.e., how is the argv that is returned via QMPI_Tool_get returned).
> - Need to specify that the strings passed in to QMPI_Tool_add are safe to be freed after QMPI_Tool_add returns (i.e., imply that the MPI implementation will make a copy of the string if it needs it)
> - Need Fortran bindings for the QMPI_* functions.
> - In the union of fields passed to the tool-provided QMPI_multiplex function for each, some functions will need to pass an enum to indicate which MPI binding the intercept came from (e.g, C, mpif.h, use mpi, use mpi_f08)
> - In all cases, the tool-provided QMPI_multiplex function will be passed the C versions of MPI handles.  I.e., if a Fortran program calls MPI_Send which ends up invoking a tool's QMPI_multiplex function, the QMPI_multiplex function will receive C versions of the communicator and datatype handles.
> 
> 3. Random thought -- do we need QMPI_Control?  This would be analogous to MPI_Control -- it would be used for communicating directly with tools.  Its first argument could be a (const char*) that corresponds to the strings that you get back from QMPI_Tool_get (i.e., allowing an app to communicate with a specific tool).

What is the benefit of having this in lieu of just having tool specific functions? If you (the application) know enough about the tool to know what to pass to QMPI_Control, why not just call a function directly from the tool’s library?

> 
> 4. We haven't crisply laid out the goals for QMPI/PMPI+1/whatever.  That is -- to paraphrase Kathryn's sentiments from yesterday: how is this interface *better* than the current PMPI world?  I think the goals are:
> 
> - Avoid relying on linker tricks (although this is kinda weak -- linker tricks work just fine in many cases, and, indeed, we're not outlawing linker tricks like LD_PRELOAD)
> - Solve all language bindings issues (e.g., allow tools to be written in C)
> - *Eventually* allow supporting N tools simultaneously
>  --> Although this is just the first step in supporting that eventual goal
> 
> And again paraphrasing Kathryn (who was channeling Adam): given that the plan is that MPI-4 won't support N simultaneous tools, are these goals enough "better" than the current PMPI to be worth doing?
> 
> I think we need a crisp, irrefutable answer for that question before going before the entire Forum.

This seems like a good start. We should also try not to disallow multiple tools as things are now. We can just stay that it’s undefined behavior, and the implementation is free to support it if desired with random ordering (or something).

Thanks,
Wesley

> 
> -- 
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools