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

[Martin Schulz]

Trying again to get this posted to the mailing list.

Martin


On Oct 1, 2011, at 9:13 PM, Martin Schulz wrote:

> 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
> 
> 
> 

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