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