[Mpi3-tools] [MPI3 Fortran] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
longb at cray.com
Mon Apr 22 07:57:10 CDT 2013
On 4/22/13 3:09 AM, Tobias Burnus wrote:
> Bill Long wrote:
>>> 2) The Fortran implementation will take the performance penalty of using
>>> a wrapper routine to perform the operation (discounting sophisticated
>>> IPA/WPA (interprocedural analysis/whole program analysis)). Taking this
>>> performance penalty is common but not universal.
>> I agree there will be call overhead for the user who accesses MPI
>> through the include file mechanism, unless, as you say, there is a
>> sophisticated IPA/WPA mode in the compiler. However, the compiler
>> does not have to be all that sophisticated to inline a module
>> routine. The compiler has to know how to find the module information
>> at compile time, and could have access to all the information needed
>> to inline the wrapper.
> My possibly wrong impression is that only the Cray Fortran compiler does
> so. I think most (all?) other compiler have a .mod file which contains
> the interface of the procedures but not the procedure code itself.
> Hence, they do not do any inlining at this stage. Those compilers will
> presumably only do this kind of optimization with multi-file
> interprocedural optimization (IPO)/link-time optimization (LTO).
> That crayftn does this inlining earlier is probably also a consequence
> of (by default) storing the module-interface information in the .o file
> instead of using a separate .mod file. If one already has the .o file,
> considering IPO is more obvious than if assembler code and module
> information are separated into .mod and .o files.
The Cray compiler has a switch (-em) that causes module information to
be put into .mod files instead of the .o file. This was added mainly to
accommodate dependency rules in exiting Make files. Inlining of module
procedures by CCE is unaffected by which method (.mod or .o) the user
chooses. I'm aware that some compilers are more aggressive about
inlining than others, which is why is wrote "could have access" instead
of "will have access" or "has access". On the other hand, most
compilers routinely inline intrinsics and procedures defined in
intrinsic modules, so the technology is available to inline "known"
routines. There is nothing to prevent them from treating the mpi and
mpi_f08 modules that are accessed from known locations the same way they
treat intrinsic modules.
The key difference with module procedures (or internal procedures or
procedures defined in the same source file) is that there is no
ambiguity as to what procedure is being referenced, so it is
theoretically possible to inline on the spot. Any particular compiler
may or may not take advantage of this. For a non-module or submodule
procedure or that is defined in a different file, you don't know until
the link step what actual procedure is being referenced (unless there
are specific compiler options to point to the desired procedure).
Waiting until the link step requires a more "heroic" effort.
> * * *
> Regarding the latest PDF, I also have two nits:
> * [p.13,ll. 5-17] The example lists several directives to disable TKR
> checks. It should add the following* to the list:
> !GCC$ ATTRIBUTES NO_ARG_CHECK
> which GCC/gfortran now supports.*
> * [p.17] The TS29113 reference should be updated now that it is an
> approved ISO Technical Specification. Additionally, the name has now an
> "of Fortran" in the name: "Further Interoperability of Fortran with C"
> and latest draft (FDTS) is N1942, which contains some minor changes. See
> and ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf
> * Cf. http://gcc.gnu.org/gcc-4.9/changes.html
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
More information about the mpiwg-tools