[MPI3 Fortran] [Mpi3-tools] Questions on the F2008 profiling interface issues

[Martin Schulz]

Hi Marc-Andre,

On Sep 30, 2011, at 6:27 AM, Marc-Andre Hermanns wrote:

> Martin,
> 
>> I was in Dresden the last few days (visiting the Vampir group, in
>> particular Andreas Knuepfer and Tobias Hilbrich who are responsible for
>> their MPI wrappers) and we sat down to talk about the issues around the
>> profiling interface in ticket #229.
>> 
>> Here is a quick summary with a few questions that came up:
>> 
>> * With the new Fortran symbol naming variants, there are 6 or 8 or 10
>> versions for every MPI subroutine. Tools could intercept all versions by
>> providing own symbols for all versions. 
> 
> If it is clear which name the symbols have, additional symbol names
> should be easy to generate, so at this stage I think it doesn't matter
> much, whether we have 6, 8, or 10 different schemes to cover. Right?

I agree - as long as we can generate a full list of names, we can intercept them all. Adding wrappers shouldn't be a problem.

> 
>> Now the problem: Within the wrapper function a tool needs to call the
>> correct PMPI call which usually is the same prefix (either '_f08',
>> '_f', '__' etc.) as the MPI call it is in. A mapping to matching C
>> functions (as most tools do it now) is not possible due to problems
>> with calling conventions for callback routines.
> 
> As far as I know our wrappers call the C routines, because we jump
> through all sorts of hoops to get a proper Fortran to C conversion and
> back. So in this regard, we need to fix this. Interestingly this has not
> popped up yet.

I agree - this is remarkable.

> 
> If we write Fortran wrappers in Fortran, how would a Fortran wrapper
> compiled with Fortran 77 have to call the C measurement code inside the
> wrapper? If the Fortran compiler implicitly adds underscores to the
> calls, do I have to provide a special Fortran interface to my
> measurement system then?

That is a question for the Fortran experts.

> 
>> * Would the following solution work? All wrappers for Fortran are written
>> in Fortran instead of C. 
>> [...]
>> For every MPI function, there are 6 or 8 variants and all of them
>> need to be provided by a tool. This would probably mean that we have
>> to compile wrappers with all three calling conventions (mpif.h, use
>> mpi_f and use mpi_f08) and then link them together?
> 
> Don't we need to compile with all three calling conventions on all
> possible compilers on a given system?

Also, here, I think the Fortran experts need to weigh in.

> 
> We currently provide all 4 name-mangling schemes with every install of
> Scalasca, because we had some issues with applications using two
> different Fortran compilers for different sub-modules. (This came up in
> a project some years back, and ever since then we provide all schemes in
> the same library and it seems to work.)
> 
>> * As discussed at the forum, if we want to keep our tools in C (which is
>> probably still the easier and better option), we need to know the symbols
>> on the "p" side and we need a portable way to figure this out. We talked
>> about the solution of two groups of routines - one for which we have _f08
>> symbols for one for which we don't. Rolf, how will you add this to the
>> standard, in particular how will you form those groups.
> 
> I started to get some doubts about this approach. One of the issues was
> that some choice-buffer routines had names longer than the proposed
> limit. So they need to be mangled differently, especially, their symbol
> needs to be shortened. And as I understood it, the current idea is to
> leave it to the MPI implementation to define the shortened name.

I thought that was just for the argument checking in mpif.h and that we decided to not support this. Are there more locations were the names are too long?

> 
> It is one thing, finding out which suffix is used. Finding how function
> names are mangled without any form of restricting to possible schemes
> seems to be another ball game?
> 
> Am I missing something?

Yes, if we do have to shorten names, I agree - I think, though, we got around the issue, or did we not?

> 
> I think, as it was pointed out in Santorini with the Fortran Bindings in
> general, we (or at least I) don't have enough Fortran expertise to think
> this through all to the end and consider all implications. I think it
> would be a great benefit to have people of the Fortran WG to join on the
> call on Monday. I hope this is possible.

Yes, that would be great - all are cc-ed.

Martin


> 
> Cheers,
> Marc-Andre
> -- 
> Marc-Andre Hermanns
> German Research School for
> Simulation Sciences GmbH
> c/o Laboratory for Parallel Programming
> 52056 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. | Dr. Norbert Drewes
> 

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