[MPI3 Fortran] MPI Data types
ritzdorf at it.neclab.eu
Thu May 7 14:02:45 CDT 2009
The function CFI_is_contiguous() is what Jeff was referencing to the last
Chicago meeting. cdesc->elem_len doesn't help the MPI programmer
since there is a special constant (MPI_BOTTOM) and other
possibilities to construct the MPI datatype. I think, there are
4 possibilities in case of an MPI_Send/MPI_Isend:
(1) CFI_is_contiguous() returns isContiguous == true and
MPI datatype is contiguous:
MPI uses cdesc->base_add and sends count elements of
the MPI datatype.
(2) CFI_is_contiguous() returns isContiguous == true and
MPI datatype is NOT contiguous:
MPI uses address cdesc->base_add and sends count elements of
the MPI datatype.
(3) CFI_is_contiguous() returns isContiguous == false and
MPI datatype is contiguous:
MPI uses the the cdesc description ( including cdesc->base_add and
cdesc->elem_len) in order to pack count data elements of the
Fortran array (similar to a Fortran copy-in; of course MPI can do
this packing on the fly).
This would be backward compatible to behaviour
of actual Fortran 90 compilers.
(4) CFI_is_contiguous() returns isContiguous == false and
MPI datatype is non-contiguous:
This is the tricky part:
(a) If MPI should be compatible to actual Fortran 90 compiler,
it must simulate the packing (copy in) and apply the
non-contiguous MPI datatype, to the packed buffer.
This corresponds to (3).
(b) Otherwise, handle the buffer and the MPI datatype
such as in (2).
Craig Rasmussen wrote:
> I'll try to be gentle to you C folk (except for Jeff of course :-)
> The MPI implementation will get an array descriptor instead of _just_
> a pointer. Consider a simple MPI_send,
> void MPI_send(CFI_desc_t * cdesc, int count, int * error)
> void * addr = cdesc->base_add; /* this is the normal address C
> expects (given some qualifications) */
> /* now for some example error checking code, not real code */
> assert(cdesc->type == the_right_MPI_type_given_by_the_user);
> CFI_is_contiguous(cdesc, &isContiguous); /* this function supplied
> by Fortran compiler */
> assert(MPI_lib_actual_size(cdesc) >= count*cdesc->elem_len); /*
> this function supplied by MPI library */
> addr = MPI_lib_actual_addr_start(cdesc); /* this function supplied
> by MPI library */
> /* now can send data */
> *error = ...
> On May 7, 2009, at 10:54 AM, N.M. Maclaren wrote:
>> On May 7 2009, Jeff Squyres wrote:
>>> I don't understand the implications of what you are saying. Be
>>> gentle with me; I'm *NOT* a Fortran expert (or anywhere close).
>> C's array model is confused, but the issue is its semantic aspect. A C
>> array is simply a pointer to the first element of a contiguous sequence
>> of an unspecified number of elements. Nothing more. A void * pointer
>> is the first byte of an unspecified length of storage of unspecified
>> type. It is assumed that it is of appropriate alignment and size for
>> it is used, but that information is not associated with an array
>> A Fortran array is strongly typed (the first difference), and it
>> comes in
>> many forms. Most of them are contiguous, but the most important
>> Fortran 90
>> one (plain assumed size) is not. All but assumed shape (a Fortran 77
>> feature) have a strongly associated size. It is the user's
>> to never pass a smaller array to a largerr argument.
>> Pretty well all combinations are allowed in argument passing, and the
>> compiler is expected to use copy-in/copy-out when needed. In
>> it is needed (in general) when passing an assumed-shape array to an
>> size argument (which is the form that matches C's model). That can be
>> locked out, but that means that callers cannot use assumed shape arrays,
>> which (as I said) are the main Fortran 90 mechanism.
>>>> I thought that we were discussing features to enable MPI-3 to
>>>> support things
>>>> like Fortran array arguments that have no equivalent in C (principally
>>>> assumed shape).
>>> I don't understand. What does it matter if there is no equivalent
>>> data type in C?
>> Not data type - semantic model.
>>> MPI is about message passing -- as long as we can get a memory
>>> layout description of the data to send / receive, then it doesn't
>>> matter what language the data will be accessed from.
>> Yes, but ....
>> The data layout is part of the MPI datatype, so there is a problem when
>> passing a Fortran 90 assumed shape REAL array (for example). If the MPI
>> datatype is REAL, the MPI send / receive needs to handle discontiguous
>> data (which it doesn't). If the MPI datatype is an MPI derived type,
>> is no direct equivalence between the Fortran and C interfaces.
>> Nick Maclaren,
>> University of Cambridge Computing Service,
>> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
>> Email: nmm1 at cam.ac.uk
>> Tel.: +44 1223 334761 Fax: +44 1223 334679
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
More information about the mpiwg-fortran