[MPIWG Fortran] F08 and pair types?

Rolf Rabenseifner rabenseifner at hlrs.de
Fri Dec 11 04:38:00 CST 2015


A few comments - shortcut: F08 and pair types
is a good idea and helps to get MPI-4.0 more consistent.


1. After the fiasco with the MPI-3.0 BIND(C) back-end and 
   a completely rewritten Fortran back-end section without BIND(C),
   I would strongly recommend to stay within Fortran without C.

One possible reason: if somebody wants to add something 
to MAX/MINLOC with a datatype that is not directly C compatible
(like LOGICAL), then we would have an inconsistent Interface.

This applies to the type of the numerical data itself, i.e.,
the following application code would fit to the
MPI datatype handle MPI_DOUBLE_PRECISION_INT_TYPE 

  TYPE MY_DOUBLE_PRECISION_INT_TYPE
    SEQUENCE
    DOUBLE PRECISION :: VAL
    INTEGER :: LOC
  END TYPE

and we should ***never*** do

  TYPE MY_DOUBLE_PRECISION_INT_TYPE
>   SEQUENCE
>   REAL(kind=C_DOUBLE) :: VAL
>   INTEGER :: LOC
> END TYPE

and it also applies to the whole stucture, i.e., 
we should ***never*** do

  TYPE, BIND(C) :: MY_DOUBLE_PRECISION_INT_TYPE
    DOUBLE PRECISION :: VAL
    INTEGER :: LOC
  END TYPE

nor 

  TYPE, BIND(C) :: MY_DOUBLE_PRECISION_INT_TYPE
    REAL(kind=C_DOUBLE) :: VAL
    INTEGER :: LOC
  END TYPE

2. The names for Fortran and C should be clearly different.

   In Fortran we should define the following datatype handles:

   - new MPI_DOUBLE_PRECISION_INT_TYPE (29 character :-)
   - new MPI_REAL_INT and
   - existing MPI_2INTEGER 
     (but with this new meaning [i.e. SEQUENCE derived type
      with two INTEGERs], which is memory-wise identical
      to the current definition of an array of two INTEGERs)

3. It is up to the MPI library to understand the 
   alignment rules for these types.

   Implication: 
   Because we will define this through MPI_TYPE_CREATE_STRUCT
   as on MPI-3.1 page 180 lines 33-42,
   we must define MPI_TYPE_CREATE_STRUCT correctly.
   This means, that the attomatic alignment epsilon on page 105
   for Fortran types must be according to the rules 
   for Fortran derived types with the SEQUENCE attribute.
   Currently it is not defined, which is bad for old MPI-1.1
   application when BIND(C) was not yet invented.
   The text of MPI-3.1 Section 17.1.15 Fortran Derived Types
   must also reflect this now well-defined definition of 
   the Fortran alignment epsilon.

   This change is a change from undefined to defined,
   i.e., existing correct MPI applications must not
   have a problem with this change.

   Some MPI libraries do not yet calculate correct 
   Fortran alignments (in this sense), because they apply 
   C alignments to Fortran types. 
   These MPI libraries must be corrected.

4. If somebody uses MPI_FLOAT_INT together with MAX/MIN_LOC
   in Fortran, then this is already allowed based on 
   MPI-3.1 page 659 lines 1-9!

   A Fortran programmer may program the buffer 
   for MPI_FLOAT_INT with 

   TYPE, BIND(C) :: my_float_int
     REAL(kind=C_FLOAT)  :: VAL
     INTEGER(kind=C_INT) :: LOC
   END TYPE

5. All said is of course valid for all three
   mpi_f08 module, mpi module, and mpif.h


I hope that my comments are not inconflicht with
previous discussions.
 
Best regards
Rolf


----- Original Message -----
> From: "Craig Rasmussen" <rasmus at cas.uoregon.edu>
> To: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>
> Sent: Friday, December 11, 2015 2:24:05 AM
> Subject: Re: [MPIWG Fortran] F08 and pair types?

> Jeff Squyres wrote:
> 
>>Hmm. Ok, that's the opposite advice we got for MPI-3.0 (which was now admittedly
>>several years ago).
>> 
>>Soo... which way should it go these days?
>> 
>>- use native Fortran datatypes
>>- use C datatypes (via BIND(C))
> 
> I don't think the advice has changed since MPI-3.0. I believe the preference is
> for the application programmer to see native Fortran datatypes, not, for
> example, REAL(C_DOUBLE). However, BIND(C) kinds can be used in the MPI_F08
> module to declare the new datatypes, e.g.,
> 
> TYPE MPI_DOUBLE_INT_TYPE
> SEQUENCE
> REAL(kind=C_DOUBLE) :: VAL
> INTEGER :: LOC
> END TYPE
> 
> as the application programmer will only use TYPE(MPI_DOUBLE_INT_TYPE) in a type
> declaration and not know that it is defined in terms of native C types.
> 
> I also don't think it matters that SEQUENCE is used to define
> MPI_DOUBLE_INT_TYPE even if it is no longer considered to be so pretty.
> However, I'm still confused by how this is used in C. Jeff S. in responding to
> Bill L. said:
> 
>>> How do you handle MPI_SHORT_INT? A short immediately followed in memory by an
>>> int will cause the int to have bad memory alignment.
>> 
>> Right. MPI knows this; MPI_SHORT_INT will include padding between the SHORT and
>> INT if it needs to.
>> 
> 
> How does a C programmer get the value returned in MPI_SHORT_INT? By accessing a
> member of a C struct? Google suggests MPI_SHORT_INT is a struct {short, int} as
> well as a pair of short integers followed by a 32 bit integer. Since these data
> types really do contain the proper amount of padding (despite what I infer from
> reading the MPI 3.1 standard), I think Bill's suggestion of declaring the
> Fortran types to be BIND(C) equivalent to a C struct is the right thing to do.
> Note that the Fortran application programmer won't ever see the BIND(C)
> attribute.
> 
> Final note: I was searching the WRONG Fortran standard document when I couldn't
> find SEQUENCE and therefore said it looked like it was no longer in the
> standard. My bad... :-(
> 
> -craig
> 
> 
> -craig
> 
> On Wed, Dec 9, 2015 at 5:45 AM, Jeff Squyres (jsquyres) < jsquyres at cisco.com >
> wrote:
> 
> 
> On Dec 8, 2015, at 6:31 PM, Bill Long < longb at cray.com > wrote:
>> 
>> As I understand the high-level situation, this is all for MPI_REDUCE and
>> friends, and MPI_2INTEGER and MPI_MINLOC or MPI_MAXLOC are all just magic
>> constants that the MPI_REDUCE routine internally decodes to determine what to
>> do. The actual data, the in and out arguments of MPI_REDUCE, are choice
>> arguments (void *).
> 
>> Current codes have the actual argument IN declared as INTEGER :: IN (2, K) where
>> K is the number of things in the list to be reduced. IN(1,*) is the “VAL"
>> value, and IN(2,*) is the “LOC” value. Since the corresponding dummy argument
>> is (void *) you can pass any actual type, since only the memory layout matters.
> 
> Correct.
> 
>> If the above is correct, then the following declarations would have the same
>> memory layouts for the actual arguments:
>> 
>> INTEGER :: IN(2, K)
>> 
>> and
>> 
>> TYPE MPI_2INTEGER_TYPE
>> SEQUENCE
>> INTEGER :: VAL
>> INTEGER :: LOC
>> END TYPE
>> 
>> TYPE(MPI_2INTEGER_TYPE) :: IN(K)
>> 
>> This seems like sugar coating for the 2INTEGER case.
> 
> Yes, exactly.
> 
> Is there a way to do it without SEQUENCE (since that is frowned upon)?
> 
>> But, the following would likely not be equivalent:
>> 
>> DOUBLE PRECISION :: IN(2, K)
>> 
>> and
>> 
>> TYPE MPI_DOUBLE_INT_TYPE
>> SEQUENCE
>> DOUBLE PRECISION :: VAL
>> INTEGER :: LOC
>> END TYPE
>> 
>> TYPE(MPI_DOUBLE_INT_TYPE) :: IN(K)
> 
> Right -- I'm not trying to make those equivalent.
> 
> To be clear:
> 
> - the only one where we need this equivalence MPI_2INTEGER.
> - the intent is to deprecate MPI_2DOUBLE_PRECISION and MPI_2REAL
> --> I assume that these are historical artifacts that were created before
> derived types existed
> - and then create 2 new types: MPI_DOUBLE_PRECISION_INTEGER and MPI_REAL_INTEGER
> --> these will be analogous to their C counterparts (but using Fortran types,
> not C types)
> 
>>> 2. I wasn't looking to emulate the C types in Fortran -- I think we've had this
>>> discussion before. The intent is to have Fortran-native types (that would be
>>> natural for Fortran programmers).
>> 
>> I think BIND(C) is “natural” for Fortran programmers these days. This stuff has
>> been around for over a decade. The use of “DOUBLE PRECISION” is far less
>> natural these days. Essentially everyone has switched to REAL(KIND= ) instead.
>> That stuff is 25 years old.
> 
> Hmm. Ok, that's the opposite advice we got for MPI-3.0 (which was now admittedly
> several years ago).
> 
> Soo... which way should it go these days?
> 
> - use native Fortran datatypes
> - use C datatypes (via BIND(C))
> 
> I.e., when users want to use MINLOC / MAXLOC in fortran, will they be using this
> across DOUBLE PRECISION values, or Type(C_DOUBLE)?
> 
> --
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> 
> 
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)



More information about the mpiwg-fortran mailing list