[Mpi-forum] Datatypes for all-to-all collectives on intercomms

Michael Knobloch m.knobloch at fz-juelich.de
Tue Apr 30 07:38:55 CDT 2019


Dan,

thanks, that was my understanding as well, as otherwise it would make
little sense.

Would it make sense to clarify that in the standard?

-Michael

On 30.04.19 12:33, HOLMES Daniel wrote:
> Hi Michael,
> 
> Personally, I would read and summarise the current MPI text about this
> as these two restrictions:
> 
> The type map described by {sendcount, sendtype} in A must be consistent
> with the type map described by {recvcount, recvtype} in B, e.g. {4,
> MPI_INTEGER} in A and {1, strided_4_integers}.
> 
> and, at the same time,
> 
> The type map described by {sendcount, sendtype} in B must be consistent
> with the type map described by {recvcount, recvtype} in A, e.g. {4,
> MPI_DOUBLE} in B and {1, strided_4_doubles}.
> 
> For an intra-communicator, or for processes in an inter-communicator
> with dual-membership (erroneous but somehow supported according to
> section 6.6.2), one of the send/recv communications for each process is
> back to that same process. Thus, these two statements constrain the
> operation to have only one type map, which is then applicable to both
> directions at all processes. That type map could be specified using
> different but consistent {count, type} parameters at each process.
> 
> So, in short, yes.
> 
> Cheers,
> Dan.
>> Dr Daniel Holmes PhD
> Applications Consultant in HPC Research
> d.holmes at epcc.ed.ac.uk <mailto:d.holmes at epcc.ed.ac.uk>
> Phone: +44 (0) 131 651 3465
> Mobile: +44 (0) 7940 524 088
> Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh,
> EH8 9BT
>> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>> 
>> On 30 Apr 2019, at 10:07, Michael Knobloch via mpi-forum
>> <mpi-forum at lists.mpi-forum.org <mailto:mpi-forum at lists.mpi-forum.org>>
>> wrote:
>>
>> Hi all,
>>
>> when looking at the semantics of all-to-all collectives on intercomms I
>> came to a point that isn't entirely clear from the standard: Am I'm
>> allowed to use different datatypes for each communication direction,
>> i.e. send MPI_INTEGERS from group A to group B and MPI_DOUBLES from B
>> to A?
>>
>> The standard says (page 168, line 38 for MPI_Alltoall, similar
>> statements for the other all-to-all collectives): The type signature
>> associated with sendcount, sendtype, at a process must be equal to
>> the type signature associated with recvcount, recvtype at any other
>> process. This implies that the amount of data sent must be equal to the
>> amount of data received, pairwise between every pair of processes. As
>> usual, however, the type maps may be different.
>>
>> This however is only true for an intracommunicator as the statement only
>> holds for every pair of *communicating* processes, which in the case of
>> an intercommunicator is not every pair of processes (though the name
>> implies a different semantics). And the advice to users (page 169, line
>> 23) contradicts that by saying that the counts may be different, but
>> says nothing about the datatypes.
>>
>> -Michael
>> -- 
>> Michael Knobloch
>> Juelich Supercomputing Centre
>> Institute for Advanced Simulation
>> Forschungszentrum Juelich GmbH
>> 52425 Juelich, Germany
>>
>> Phone:  +49-2461-61-3546
>> Fax:    +49-2461-61-6656
>> E-mail: m.knobloch at fz-juelich.de <mailto:m.knobloch at fz-juelich.de>
>> WWW:    http://www.fz-juelich.de/jsc/
>>
>> _______________________________________________
>> mpi-forum mailing list
>> mpi-forum at lists.mpi-forum.org
>> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
> 

-- 
Michael Knobloch
Juelich Supercomputing Centre
Institute for Advanced Simulation
Forschungszentrum Juelich GmbH
52425 Juelich, Germany

Phone:  +49-2461-61-3546
Fax:    +49-2461-61-6656
E-mail: m.knobloch at fz-juelich.de
WWW:    http://www.fz-juelich.de/jsc/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5343 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20190430/a49700ee/attachment.p7s>


More information about the mpi-forum mailing list