[Mpi3-tools] [MPI3 Fortran] Issues with Fortran bindings for MPI_Pcontrol

[Marc-Andre Hermanns]

Hi Martin,

>>> On 4/15/13 4:38 PM, Schulz, Martin wrote:
>>>> As a first simple approach, this could be done with
>>>>
>>>> MPI_Pcontrol_new(MPI_Info info)
>>>
>>> The original question seemed specific to the Fortran interface for MPI_PCONTROL.  Would it be possible to keep the C interface, either as is or modified as suggested above, but delete the Fortran interface for this routine?  That solves the immediate issue.
>>>
>>> I would argue that the few people who use this routine are "expert users" who would have little trouble writing their own MY_PCONTROL, written in C but callable from Fortran that had whatever interoperable arguments were desired, and internally called the C MPI_Pcontrol function.
>>
>> Or not even bother with MPI_Pcontrol, because it's less hassle to
>> implement the whole thing from scratch and provide their own interfaces.
>> I agree - this isn't likely to impact more than 0.1% of users, who are
>> quite capable of resolving any difficulties.
>
> I don't think that's quite true - Pcontrol is useful in many cases
> and is used by profilers (that are advertised as easy to use). It is
> certainly a bit more advanced usage, but in many cases we tell users
> where to put it, so they can run their code and get data, but it has
> to be easy for them to add it or they won't do it. Having to go
> through C in Fortran codes is not really a workable solution in this
> case. That's also how we ran into the problem that we are discussing:
> we had a user new to performance analysis during a tutorial and he
> wanted to profile a particular snapshot and so we asked him to add
> the calls. Due to the ierr issue, this crashed the code.

But where did it crash? In the MPI library or in the profiler?

> The only way to make only having a C call work would be a separate
> library, but then that defeats the purpose of adding something that
> can just stay in the code without having to link to special libraries
> (which was the main reason for adding MPI_Pcontrol). MPI_Pcontrol is
> (unlike MPI_T) intended to be used in the application code and hence
> should have bindings in all languages supported by MPI.

What I still don't understand about Pcontrol is that the varargs make it 
inherently non-portable, or not? I don't mean the "portablility" between 
C and Fortran, I mean: If the call to MPI_Pcontrol takes anything else 
than the initial 'level' it will very likely crash with the use of 
another tool that expects different parameters. If the user has to 
modify the code for using a different tool to use a feature, I would 
argue against its portability.

I think the only way of handling this portably would be if the call 
itself, took a handle-like identifier, and the tool itself would 
implement another call that creates the opaque object behind it.

Something along the lines of:

int MPI_Pcontrol_create(MPI_Pctrl* handle);
int MPI_Pcontrol_free(MPI_Pctrl* handle);

The idea is that the Profiling tool would not call PMPI_Pcontrol_create 
but just create the a structure, do its own book-keeping and return the 
handle.

Then Pcontrol takes this handle (which can transport anything the 
profiling tool would expect)

int MPI_Pcontrol(int level, MPI_Pctrl handle);

and maybe something like:

int MPI_Pcontrol_set(MPI_Pctrl handle, MPI_Info info);

If the tool does not understand some of the infos (because they are 
meant for a different tool) it ignores it and should use some form of a 
consistent default state.

But I don't know if the latter would really improve over your initial 
proposal with the info object as a parameter to the Pcontrol call 
itself, as I don't have any experience with how often one would have to 
modify the handle. If you have to modify the handle with every call, 
then you don't gain anything.

Cheers,
Marc-Andre
-- 
Marc-Andre Hermanns
German Research School for
Simulation Sciences GmbH
c/o Laboratory for Parallel Programming
52062 Aachen | Germany

Tel +49 241 80 99753
Fax +49 241 80 6 99753
Web www.grs-sim.de

Members: Forschungszentrum Jülich GmbH | RWTH Aachen University
Registered in the commercial register of the local court of
Düren (Amtsgericht Düren) under registration number HRB 5268
Registered office: Jülich
Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt