[Mpi3-tools] Issues with Fortran bindings for MPI_Pcontrol

[Schulz, Martin]

Hi Jeff,

On Apr 15, 2013, at 3:03 PM, "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
 wrote:

> On Apr 14, 2013, at 9:01 PM, Jeff Hammond <jhammond at alcf.anl.gov> wrote:
> 
>> It seems better to correct the text than to break the existing
>> definition of MPI_PCONTROL.  What error code would be returned
>> anyways?
> 
> 
> I think the point is that we don't know what could/would be returned by Pcontrol, because Pcontrol can be subsumed by a profiling library, and therefore it can do whatever it wants.
> 
> The issue here is that the C API is varargs, and therefore allows you to pass in whatever you want to Pcontrol (at least in C), and therefore a tool (or the underlying C MPI API) can document what arguments it expects.
> 
> There's (at least) two problems with this:
> 
> 1. If a profiling library and the MPI library have differing arguments that they expect, even though varargs makes the different signatures compile-time safe, there could still be run-time errors (this is a contradiction that I've never understood in the definition of Pcontrol).
> 
> 2. Fortran has no varargs.  Prior to MPI 2.2, we actually did have a "..." in the Fortran prototype to indicate that you could do whatever you wanted for this signature.  And that was fine in the days before strict dummy argument type checking.  But now we mandate struct signature checking, and ... had to go, because it's not legal Fortran.  And now the text doesn't say "Fortran implementations can add whatever parameters they want" (which has problems, anyway).
> 
> I'm really in favor of ditching the PMPI layer and putting something better there.

I wouldn't go that far - the PMPI interface idea has been very successful and extremely useful and has lead to significant tool support. I think getting rid of it would be a huge setback.

I do agree, however, that the current Pcontrol is problematic, especially with the more and more creative uses of the PMPI interface. In most cases tools only use the single integer and in some of our tools we started using one additional argument (often a pointer) to transfer extra information. Hence, stepping back from the vargs in C is likely not a problem for any tool.

The bigger issue is that the current scheme basically makes the Pcontrol calls tool specific (i.e., they must be added targeted for a specific tool). This was fine when Pcontrol was mainly used for turning on and off profiling, but we are now using that interface to communicate application information to the tool (e.g., phase boundaries, load balance data, …). These are all things that should stay in the code for easier maintenance and hence an application would have to be able to specify a target tool and a tool must be able to filter calls not intended for it. We started doing this using magic numbers as the arguments, but this is obviously far from ideal. Better would be some kind of name space that tools put themselves into and pass that as an argument. 

As a first simple approach, this could be done with

MPI_Pcontrol_new(MPI_Info info)

but the need for string parsing on every MPI_Pcontrol call could be a problem.

Martin




> 
> -- 
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
> 

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA