[mpiwg-tools] Per the QMPI/PMPI+1/whatever discussion yesterday
schulzm at llnl.gov
Thu Dec 11 04:02:01 CST 2014
Hi Jeff, all,
On 12/10/14, 7:59 AM, "Jeff Squyres (jsquyres)" <jsquyres at cisco.com> wrote:
>On Dec 9, 2014, at 11:10 AM, Martin Schulz <schulzm at llnl.gov> wrote:
>> Is this intended as temporary internal name or for the standard at the
>Name for the standard.
>> For the former, it¹s fine, but I don¹t think it¹s a good idea to have
>> a special name space in the MPI standard. The forum already hated the
>> of MPIT and we had to change it to MPI_T. Also, most of these functions
>> are also intended for users, so why shouldn¹t they be normal MPI
>That's a fair point, and I don't have a good answer.
>It's just a subjective feeling that a "QMPI_" namespace is good to be
>separate to indicate that you're talking with tools, not really the MPI
The two or three routines are not really directed at the tool, they inform
the MPI implementation what tools want to do with it.
Either way, we can discuss once we have a concrete API proposal.
>> We conquered (I think?) the biggest problem we had with multiple tools,
>> the specification of which tools to load (this was the main reason why I
>> suggested to limit the proposal). I think the dependencies are easy,
>> leaves ordering. Perhaps we should have at least some support for this
>> already in the proposal.
>Well, hmm. There's still multi-tool problems, though -- e.g., ordering,
>pre/post side effects, replacement (i.e., tool A not getting called for
>MPI_Send because tool B decided to implement MPI_Send as
>But perhaps you could convince me. :-)
>Do you want to sketch something out and come back with some ideas?
Yes, I’ll do that, but need to think about it a bit more.
>jsquyres at cisco.com
>For corporate legal information go to:
>mpiwg-tools mailing list
>mpiwg-tools at lists.mpi-forum.org
More information about the mpiwg-tools