[Mpi-22] Should all constants/types beavailablein all languagebindings?

[Supalov, Alexander]

Hi,

Yes, it appears that if p483:46-47 are to be interpreted literally, any
implementation that does not provide all datatypes in all languages will
be non-compliant with MPI-2.1. More on this below. For now, a bit of
fun:

Re C handle produced out of the Fortran MPI_REAL - imagine it's
MPI_FLOAT. Will anything change for the MPI_Send? Probably, no. The
datatype signature would be different if the struct was created directly
in Fortran, but the MPI_Send would not suffer a jot.

Re MPI_Fint, C++ defines to many C++ entities that have C equivalents,
like MPI::REAL, MPI::SEEK_SET, etc. Why should the user rely on MPI_Fint
then? More generally, where is the boundary between the C++ and C
interfaces, or, how much of C++ should really look like C++?

So far I was pulling your let a little. Now it's getting serious. There
are four things to consider:

1) Language independent datatype definition - say, MPI_INTEGER (see
p27:13).
2) Language binding for the datatype handle representing 1) in actual
programs - say, C MPI_Datatype MPI_INTEGER, C++ MPI::INTEGER, and
Fortran INTEGER MPI_INTEGER.
3) Internal representation of the MPI datatype inside the MPI library
referenced by 1) and 2).
4) Actual format of the data in memory defined by the language and
platform, and referenced by 1), 2), and 3).

Note that distinction between 1) and 2) sort of justifies existence of
so specifically C++ binding MPI::INTEGER for otherwise mundane entities
in C and Fortran. The argument for MPI::Fint arises from this
observation: if we started to do things C++ way, let's stick to this.

And what I was talking about re example in p483 was basically a play
between 2) and 4): what is different for the user may actually be the
same thing for the platform, in this case - typically a machine word
interpreted as a real value. See p. 490 for an acknowledgement of this
fact (about nonportable possibility to receive MPI_INTEGER as an
MPI_INT).

Finally, at the moment a part of the standard (see pp. 27-28) does not
seem to differentiate clearly between 1) and 2), while another part (see
pp. 483-484) talks about making 1) available in all languages thru 2),
and Appendix (pp 494-495) serves as the only definition of the datatype
equivalence. This, in addition to practical aspects mentioned in earlier
messages, is probably why so many implementations are noncompliant with
MPI-2.1.

Best regards.

Alexander 

-----Original Message-----
From: mpi-22-bounces_at_[hidden]
[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres
Sent: Friday, October 24, 2008 9:13 PM
To: MPI 2.2
Subject: Re: [Mpi-22] Should all constants/types beavailablein all
languagebindings?

On Oct 24, 2008, at 2:03 PM, Supalov, Alexander wrote:

> If this requirement is to be interpreted literally, then yes, the
> standard must define all datatypes in all languages. However, the
> example following this statement shows how an MPI_REAL is transformed
> into an equivalent C data type. Whether or not this is indeed MPI_REAL
> is not clear. It may well be an MPI_FLOAT.

I'm not sure what you mean -- Example 16.16 shows making a combined  
datatype with 1 C int and the 5 Fortran REALs.  The C code never tries  
to use the values in the R array; it just MPI_SEND's them.  Using the  
MPI_REAL type passed up from Fortran is the right thing to do here  
(vs. using MPI_FLOAT).  Alternatively, if the C code knew that the  
buffer was 5 reals, it wouldn't need to have a type passed in from  
Fortran -- just the buffer.  Then it could TYPE_CREATE_STRUCT with  
MPI_INT and MPI_REAL and send using the resulting datatype.

That's exactly why the datatypes are supposed to be defined in all  
languages, right?  Not for dereferencing, but for sending/receiving  
data that originally came from another language.

The way I read Hubert's text (p483:46-47), none of us are 2.1  
compliant because we don't offer *all* the datatypes in all  
languages.  Right?

> By the way, this example shows that MPI::Fint may be necessary:  
> MPI_Fint
> is used here to pass Fortran datatype thru the C function boundary.
> Imagine a C++ function. There was a ticket #4 calling for removal of  
> the
> MPI::Fint until it was redefined.

Why not use MPI_Fint?


-- 
Jeff Squyres
Cisco Systems
_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.