[Mpi3-tools] Fwd: [MPI Forum] #228: MPIR Specification - An Official Companion Document for the MPI Standard
John DelSignore
John.DelSignore at roguewave.com
Thu Oct 7 09:12:32 CDT 2010
Jeff Squyres wrote:
> Martin / John --
>
> Can you comment on Alexander's comments?
In-line below...
> Begin forwarded message:
>
>> From: "MPI Forum" <mpi-22 at lists.mpi-forum.org>
>> Date: October 7, 2010 7:16:50 AM EDT
>> Subject: Re: [MPI Forum] #228: MPIR Specification - An Official Companion Document for the MPI Standard
>>
>> #228: MPIR Specification - An Official Companion Document for the MPI Standard
>> ---------------------------------------------------------+------------------
>> Reporter: schulzm | Owner: jsquyres
>> Type: Enhancements to standard | Status: new
>> Priority: Had 1st reading | Milestone: 2010/10/11 Chicago, USA
>> Version: MPI 3.0 | Keywords:
>> Implementation: Unnecessary | Author_bill_gropp: 0
>> Author_rich_graham: 0 | Author_adam_moody: 0
>> Author_torsten_hoefler: 0 | Author_dick_treumann: 0
>> Author_jesper_larsson_traeff: 0 | Author_george_bosilca: 0
>> Author_david_solt: 0 | Author_bronis_de_supinski: 0
>> Author_rajeev_thakur: 0 | Author_jeff_squyres: 0
>> Author_alexander_supalov: 0 | Author_rolf_rabenseifner: 0
>> ---------------------------------------------------------+------------------
>>
>> Comment(by asupalov):
>>
>> We identified three possible issues in the current spec, see below.
The MPIR document describes the how the original interface was implemented in MPICH-1 in the mid-1990's, plus modifications and extension that have been made to the interface over the past 10 to 15 years.
What I have seen is that various MPI implementations choose implement the MPIR interface slightly differently, according to their own sense of style and to accommodate the various tool-chains (compiler, linker, etc.) they wish to support. So in that sense, there is no one "right way" to implement the interface.
>> 1. The proposal requires the VOLATILE macro to be defined (p.15, top).
Originally, the MPIR interface was compiled with compilers that did not support the volatile keyword. To accommodate those compilers, the interface did not require that the MPIR variables be declared volatile. So, the interface defined the VOLATILE macro so that an MPI implementation could exclude the volatile keyword if it knew that the compiler and hardware did not require it to properly read and write the MPIR variables.
>> What happens if VOLATILE expands to nothing?
Either the right thing or the wrong thing. It depends on the compiler, hardware, and debugger tracing interface.
All of the compilers/hardware combinations I've dealt with so far seem to properly read/write the MPIR variables from/to memory, probably because: (a) they are all global variable, (b) the debug interface has to be compiled for debugging and is typically not optimized, and (c) the MPI starter process is being traced by the debugger and that causes the caches to be flushed.
>> How will the respective
>> compiler understand that it should go down to the memory every time a
>> variable is queried? Not our problem, but still. :)
That's an implementation detail. It's the responsibility of the MPI implementation to make sure that: (a) when an MPIR variable is written by the MPI starter process that the debugger will read that value, and (b) when an MPIR variable is read by the MPI starter process it will read the value that is written by the debugger. In most implementations, nothing special needs to be done, but occasionally variable have to be declared volatile, or other special measures have to be taken to make sure the compiler or linker does not optimize out the variables.
For example, some linkers are pretty smart and will optimize out variables that are not both read and written.
>> 2. Intel MPI (and most likely MPICH2) has a bit different definition for
>> MPIR_PROCDESC table (p.15, bottom).
>>
>> Our defition:
>> typedef struct MPIR_PROCDESC {
>> const char *host_name;
>> const char *executable_name;
>> int pid;
>> } MPIR_PROCDESC;
That's fine.
The debugger needs to know two things about each of the fields: the offset of the field inside the structure, and the length of the field. The type of the host_name and executable_name fields is "pointer to const char" vs. "pointer to char", and the only thing the debugger needs to care about is offset/length of the pointer itself. Unless the debugger is being super paranoid or super stupid, it doesn't need to care about target type of the pointer. A debugger worth its salt won't get tripped up by the "const".
>> Proposal:
>> typedef struct MPIR_PROCDESC {
>> char *host_name;
>> char *executable_name;
>> int pid;
>> } MPIR_PROCDESC;
Again, it's not a proposal. It more like recorded history and the state of current practice.
>> Our definition seems to be more strict. I don't think this will cause any
>> problem, but you may want to review this and allow for the above
>> extension, as we'd not like to change the source code unless absolutely
>> necessary.
I wouldn't call this an extension, I'd call it a variation. Other variations are possible. For example, the order of the fields might be different, or there may be additional fields in the structure.
I don't think the Intel MPI or MPICH2 needs to change the definition of the structure, and I don't think that the MPIR document needs to describe every possible variation of how the structure might be defined.
>> 3. Same issue for MPIR_debug_state (p. 17, bottom).
>>
>> Our definition:
>> volatile int MPIR_debug_state
>>
>> Proposal definition:
>> int MPIR_debug_state
>>
>> This may be material, as the MPIR_debug_state is set by the program and
>> inspected by the tool. We should probably add VOLATILE to the proposal.
I think you're right, the document needs to be updated. I looked back at the original text document that described the interface, and it has:
extern VOLATILE int MPIR_debug_state;
See: http://www.mcs.anl.gov/research/projects/mpi/mpi-debug/attach.h.html and http://www.mcs.anl.gov/research/projects/mpi/mpi-debug/mpich-attach.txt
Cheers, John D.
>> --
>> Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/228#comment:3>
>> MPI Forum <https://svn.mpi-forum.org/>
>> MPI Forum
>
>
More information about the mpiwg-tools
mailing list