[Mpi3-tools] Current Version of the MPIR document

[John DelSignore]

Hi Ashley,

My comments are in-line below...

Ashley Pittman wrote:
> On 14 Jun 2010, at 17:27, Martin Schulz wrote:
> 
>> Hi all,
>>
>> Attached is the latest and updated version of the MPIR document, which John
>> DelSignore put together. The intent is still to publish this through the MPI forum
>> as an official document. The details for this are still tbd. and Jeff will lead a
>> discussion on this topic during the forum this week.
> 
> I think this is a good document and a huge step forward, I've learnt a few things I hadn't realised about the interface before.
> 
> Largely I'm in agreement with the document but I disagree with some parts of and would like clarification on a few aspects of MPIR_PROCDESC.
> 
> Section 9.2
> 
> Like the original work this document specifies a definition for MPIR_PROCDESC, it however then goes on to say that the definition isn't fixed but rather is up to the implementation.
> 
> typedef struct {
>   char *host_name;
>   char *executable_name;
>   int pid;
> } MPIR_PROCDESC;
> 
> Section 9.2 paragraph 4:
> The pid member is the integer process identifier of the MPI process. Note that historically pid was defined as a C language int, which is an integer of an unknown size, which might be smaller than the size of a process identifier for the target system. Implementations should define pid as an integer size that is large enough to hold a process identifier for the target system. For example, implementations should use pid_t as the type of pid provided that pid_t is an integer type.

I believe that that paragraph is accurate. The intent of MPIR has always been that the layout and sizes of the fields in MPIR_PROCDESC and the size of MPIR_PROCDESC itself are communicated through the debug information, and that the offsets and sizes were not hard-coded into the debugger. It was done this way for portability and to allow MPI implementations to rearrange the fields or toss extra fields into the structure.

> Are there MPI librarys in existence which don't use int as the type for pid?

I don't know, but I'd guess there could be. I have some vague recollection that on Cray Catamount, pids were 64-bit and MPI was supported, so it's likely that MPI used 64-bit pids. Also, I think that IRIX has 64-bit pids, but SGI MPI didn't use the MPIR interface, they used "array services".

>  I've certainly not seen any and never seen it necessary to read the type of MPIR_PROCDESC because it's type is well specified.

Just because you haven't seen any doesn't mean that they don't exist. You've been cheating and getting away with it.

>  Actually MPICH2 tried changing this recently from a int to a long and I made them change it back.

Well, if they were going to change it, they should change it to pid_t.

> Following on from this I don't believe that section 4.1 applies, or at least not as strictly as it's written currently.

I disagree. There may be cases where reading the type information is not necessary, but I also believe that there could be cases where it is.

>  It's possible to extract the information from the starter process without the debug information being present.

What would you like it to say? "If your tool doesn't care about portability it can hard-code the offsets and sizes of the fields in MPIR_PROCDESC and the size of MPIR_PROCDESC itself into the tool."

You can probably get away without reading the type information for MPIR_PROCDESC for a large number of MPI implementation. And in fact it might be a reasonable fall-back position if the MPI starter is void of type information. But, the intent of the interface was to make it portable by requiring the tool to read the type information for MPIR_PROCDESC.

Yes, I know that stinks, but that's the way it is, and hopefully we won't make that mistake again.

Finally, feel free to propose changes to the existing description, and we can discuss it in an MPI Tools WG concall.

Cheers, John D.


> Ashley.
>