[Mpi-22] Should all constants/types be available in all languagebindings?

Jeff Squyres jsquyres at [hidden]
Fri Oct 24 08:56:46 CDT 2008



You're right, I was not checking 2.1 implementations.

While 2.1 changelog item 2 does specifically mention those constants  
in all 3 languages, what about the other datatypes?  (e.g., MPI_INT  
vs. MPI_INTEGER, etc.?)

Per Alexander's comments:

1. Why would we artificially limit what types can be accessed from  
each language?  "Probably never" is not really the same thing as  
"never."  It may not be probable, but it is conceivable that a C++  
program could call a Fortran computational library -- perhaps the C++  
program is essentially the "driver" for a master/worker model, and the  
Fortran computational library is what does the back-end work.   
Exporting new handles for already-existing MPI objects to a specific  
implementation's language bindings is not a lot of work.

2. Regardless of which way we go, I think that the standard should be  
explicit about which constants are available in which language.   
Otherwise, codes have the danger of not being source code compatible  
if different implementations make different decisions.

On Oct 24, 2008, at 9:43 AM, Hubert Ritzdorf wrote:

> Hi,
>
> as far as I remember it was cleared in the MPI 2.1
> standardization process that "all" datatypes have to be
> defined in all 3 languages.
> Changelog item 2 requires this explicitly for MPI_LONG_LONG,
> MPI_LONG_LONG_INT, ...
> (But I think that some C++ datatypes are missing since there wasn't
> defined a name).
>
> Possibly, Jeff is not referencing MPI 2.1 implementations.
>
> Supalov, Alexander wrote:
>> Hi,
>>
>> I think we should answer the following questions to decide whether  
>> and
>> how to define the constants:
>>
>> 1. When would a C MPI program call Fortran MPI subprogram? Probably,
>> never.
>> 2. When would a Fortran MPI program call a C MPI subprogram?  
>> Sometimes.
>> 3. When would a C++ MPI program call Fortran MPI program? Probably,
>> never.
>>
> I don't agree. I know some programs of this kind.
>
> Hubert
>> 4. When would a Fortran MPI program call a C++ MPI program? Probably,
>> never.
>>
>> Here, "subprogram" means a part of program that relies on the MPI  
>> use or
>> knowledge of MPI datatypes, etc. This may or may not be a direct call
>> into the respective MPI library.
>>
>> >From this, what is needed is to define Fortran datatypes from  
>> mpif.h in
>> C mpi.h. The rest does not seem relevant. Even the existing C++
>> definitions may just reflect C heritage.
>>
>> Best regards.
>>
>> Alexander
>>
>> -----Original Message-----
>> From: mpi-22-bounces_at_[hidden]
>> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres
>> Sent: Thursday, October 23, 2008 10:13 PM
>> To: MPI 2.2
>> Subject: [Mpi-22] Should all constants/types be available in all
>> languagebindings?
>>
>> I notice that OMPI, MPICH2, Intel MPI, and HP MPI all do the  
>> following:
>>
>>  * define Fortran datatypes in mpi.h (e.g., MPI_INTEGER, MPI_DOUBLE)
>>  * define Fortran datatypes in the C++ MPI namespace (e.g.,   
>> MPI::INTEGER, MPI::DOUBLE, etc.)
>>  * do *not* define C datatypes in mpif.h (e.g., MPI_INT,  
>> MPI_FLOAT,  etc.)
>>
>> Why?  AFAICT, there is no rule about what constants have to appear  
>> in  which language bindings.  But doesn't that implicitly mean that  
>> all  constants are supposed to appear in all language bindings?
>>
>> (the argument for having MPI_DOUBLE available in C, for example,  
>> is  that a C routine may be invoked to send or receive a message   
>> containing Fortran data.  Similar arguments exist for why you'd  
>> want  MPI datatypes from other languages available in your language)
>>
>> This is also related to whether the type MPI::Fint should exist or  
>> not.
>>
>> I just filed a ticket about these issues
>> (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/56 ) and  
>> marked it as "feedback requested", meaning that I need feedback   
>> from the Forum before a proposal can be made.
>>
>> What do people think?
>>
>>
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22


-- 
Jeff Squyres
Cisco Systems




More information about the Mpi-22 mailing list