[MPI3 Fortran] [Fwd: add TYPE(*) and DIMENSION(..) to Fortran]

Aleksandar Donev donev1 at llnl.gov
Mon Sep 8 12:10:02 CDT 2008


Hi,

> E.g., if I call MPI_SEND with foo(13,  
> 10:20, 1:5), will MPI get a contiguous region of memory (which it  
> always seems to today...?), or will we get a descriptor that a) points  
> to the beginning of the memory, and b) has a description of the layout?
>
> I *think* you're telling me that we can have it both ways (let's  
> assume blocking MPI_SEND for the moment, for simplicity):
Yes, you can have both ways.

> 1. an MPI_SEND that takes an explicit MPI datatype argument and  
> returns contiguous memory (probably a copy if the original memory is  
> not contiguous). 
Declare the dummy argument in the interface to MPI_Send as:

type(*), dimension(*) :: buffer

This is how the present MPI bindings work, but without the type(*) which 
avoids the problem with type matching.

> It is this case that could be problematic if the   
> user specifies an MPI datatype that reflects the true sparseness of  
> the memory, but the compiler has copied it into a temporary contiguous  
> buffer.
Yes, that is a problem [also exists in present bindings unless you pass 
foo(13,  10, 1) as the actual without the section subscripts].

The type(*) proposal assumes that the type is *assumed* from the actual, 
rather than being some "type-map" defined externally to the language.

If you want to do type-maps, then use:

type(c_ptr), value :: buffer ! Fortran 2003

which explicitly passes the base address (C address) of the buffer to MPI. 
Then inside MPI you can address memory as you wish. The buffer that is passed 
must have the TARGET attribute and be of interoperable type (BIND(C) type).

> 2. an MPI_SEND that takes no MPI datatype argument but passes the  
> Fortran descriptor to MPI, so that MPI can build up its own MPI  
> datatype and use that instead of having the user explicitly mention  
> it. 
Yes, you can, just declare the dummy argument in the interface to MPI_Send as:

type(*), dimension(..) :: buffer

> This could be expensive if the type map is complex (e.g., non- 
> contiguous), especially for short messages.  If the type map is simple  
> (e.g., contiguous, single pre-defined Fortran type -- not a Fortran  
> user-defined struct), we might be able to have a simple switch/case  
> (or a set of overloaded functions or ...) that can deduce the correct  
> Fortran datatype -> MPI datatype mapping properly.
Yes, I was expecting something like an internal switch.

And yes, you are right that this is "building on top of MPI". You are adding a 
high-level interface on top of a work library. I don't see what is wrong with 
that. It can be external to MPI-3 document itself, i.e., it can be a Fortran 
module that is added to the standard C MPI-3 bindings. Say a techical report 
of some sort.

Hope this clarified. Feel free to ask more questions. Conference calls are 
fine with me too but they have to be after 10am pacific time and scheduled at 
least a day in advance.

Thanks.
Aleks

-- 
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev




More information about the mpiwg-fortran mailing list