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

[Jeff Squyres]

On Sep 5, 2008, at 7:13 PM, Craig Rasmussen wrote:

>> interface MPI_xxx
>>  subroutine MPI_xxx (buffer, n, ierr) bind(c,name="MPI_xxx_fortran")
>>     type(*),dimension(*) :: buffer
>>     integer(c_int),value :: n, ierr
>>  end subroutine MPI_xxx
>> end interface MPI_xxx
>>
>> And then then MPI will still have to have a "wrapper" function (in  
>> C or Fortran; whatever they want) to call the back-end/"real" MPI C  
>> function.
>
> Actually BIND(C) will be used as you show in your example, just not  
> directly to call the C MPI implementation.

Right -- in my example, it was calling another C function in the MPI  
implementation (MPI_xxx_fortran), which would be a wrapper that would  
do whatever translation is necessary before/after calling the real  
back-end C MPI function(s).

> The really cool thing to come out of TYPE(*) and DIMENSION(..) is  
> that the programmer can pass array sections in and have the wrapper  
> pull out the appropriate portions of the array and do the correct  
> thing.

This was also a question -- can we access the parts of the  
descriptor?  If so, can we only do so from Fortran?  (I assume the  
answer is "yes", particularly if the new ASYNCRONOUS stuff got  
rejected, because that assumedly would have been for the express  
purpose of supporting asynchronous libraries in other languages)

> If the array section is non-contiguous, what is the right thing to  
> do?  Should the wrapper make a contiguous copy of the array or is  
> there a more efficient way to sent the contiguous portions of the  
> array via MPI, perhaps using a lower level protocol?


I like Aleksander's approach (use dimension(*) and have the compiler  
copy).  :-)

We *could* do something more intelligent, but it's questionable as to  
whether it would be better performance (i.e., construct a type map  
struct and have the MPI datatype engine do the heavy lifting -- but  
the process of building that type map may be expensive, depending on  
the complexity and size of the data.  I'm sure there's a tradeoff  
somewhere, but it might be hard to precisely nail down, and will  
likely vary on lots of different variables).

-- 
Jeff Squyres
Cisco Systems