[MPI3 Fortran] WG mission statement / bullets

[Bill Long]

MPI constants whose values depend on settings of default size command 
options (-i8,...) can be easily handled if you have separate modules for 
each size setting. This issue is more problematic if you want to try to 
make a single module that works everywhere.  The fact that MPI is not 
intrinsically aware of the host language's data typing system is a 
fundamental design feature/flaw.  I don't see any alternative that is 
not highly disruptive. The current proposal leans heavily toward the 
conservative side; massive disruption seems off the table.

Cheers,
Bill



Supalov, Alexander wrote:
> Hi,
> 
> Let's not forget about MPI datatypes. My personal favorite is MPI_2INT. 8 bytes in 32-bit mode, 16 bytes for -i8. This is just to highlight that the effect of the -i8, etc., upon MPI may spread well beyond the language interface as we normally know it.
> 
> Best regards.
> 
> Alexander 
> 
> -----Original Message-----
> From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Bill Long
> Sent: Thursday, September 03, 2009 3:36 PM
> To: MPI-3 Fortran working group
> Subject: Re: [MPI3 Fortran] WG mission statement / bullets
> 
> 
> 
> Iain Bason wrote:
>> On Sep 3, 2009, at 5:14 AM, N.M. Maclaren wrote:
>>
>>> I haven't seen the mission statement for the same reason as Malcolm,
>>> but would favour MPI using Fortran default integers whereever they
>>> make sense.  Fortran's semantic specification of them is still useful
>>> in a way that C's isn't.
>> I believe that the idea behind using C int (or, more generally, 
>> something like a MPI_DEFAULT_INT kind) was to allow people to build a 
>> library that would work regardless of whether the application is 
>> compiled with -i8.  As it stands, the MPI Fortran library has to be 
>> compiled with -i8 if the application is.  If people use an explicit kind 
>> for their integers, then one library can serve applications with and 
>> without -i8.
> 
> With the current MPI setup, we (as a vendor) supply two sets of 
> module/library, compiled with 32-bit and 64-bit defaults respectively. 
> The compiler figures out which to use based on what the meaning of 
> "default" is based on the compile options. This is extra work to 
> maintain, but it works for the user (mostly). Until some clown wants -r8 
> -i4, in which case a third version is needed.
> 
> The advantage of explicitly specifying a KIND for the MPI dummy 
> arguments is that it encourages (forces) users to supply actual 
> arguments with the correct kinds.  This avoids hidden problems of 
> supplying an actual argument with a value that is too large to fit into 
> the 'int' that is used in the actual implementation routine.
> 
> The downside is that some existing codes will start getting error 
> messages about mismatched interfaces.
> 
> 
>> There are, of course, other possible solutions to the problem.  Is there 
>> one in particular that you favor?  Or do you think the problem shouldn't 
>> be solved?
> 
> 
> I think the better alternative is to make the user-called names generic, 
> and have the interface specify two specific interfaces, one for 32-bit 
> and one for 64-bit.  Both specifics would correspond to wrapper 
> routines; in the wrappers you would cast the integer arguments to 
> integer(c_int) before passing them on to the underlying C MPI functions. 
> Perhaps you would need 3 specifics if you want to cover the dreaded 
> -r8/-i4 case as well.
> 
> The advantage of the generic version is that the vendor need only supply 
> one MPI module and one library.  This simplifies the implementation and 
> also avoids errors such as the user forgetting to include the -i8 on the 
> link command to trigger getting the 'right' library.
> 
> Cheers,
> Bill
> 
> 
> 
>> Iain
>>
>> _______________________________________________
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
> 

-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120