[mpi3-coll] Neighborhood collectives round 2: reductions
Jed Brown
jedbrown at mcs.anl.gov
Sun Dec 9 18:55:51 CST 2012
Understood. May I ask what is the application motivating this routine?
On Dec 9, 2012 1:14 PM, "Torsten Hoefler" <htor at illinois.edu> wrote:
> On Sat, Dec 08, 2012 at 12:49:35PM -0800, Jed Brown wrote:
> > On Sat, Dec 8, 2012 at 11:12 AM, Torsten Hoefler <[1]
> htor at illinois.edu>
> > wrote:
> >
> > Hi all,
> >
> > We discussed the neighborhood reductions at the last Forum and the
> straw
> > vote if we should include them in the next revision was:
> >
> > - yes: 18
> > - no: 0
> > - abstain: 3
> >
> > I addressed all the issues in the draft that were brought up at the
> > Forum. The new draft is now at [2]
> http://www.unixer.de/sec/topol.pdf .
> > Look
> > for ticket "XXX".
> >
> > The other interfaces for MPI_Ineighbor_reduce do not contain the "I"
> (page
> > 40, line 25 and 30); MPI_Ineighbor_reducev
> > does not have the "v" (page 41, line 26 and 31).
> Thanks! Those are fixed. http://www.unixer.de/sec/topol.pdf
>
> > One open question remains: would a single send buffer for
> > neighbor_reduce suffice or do we need one buffer per destination
> > process? The second case could always be done with neighbor_reducev
> > (with small additional costs). This questions is more to the
> potential
> > users (Jed etc.).
> >
> > My understanding of Neighbor_reducev is that I send different sizes to
> > each neighbor, but receive the same size from every neighbor (reducing
> > into exactly one buffer).
> That is correct.
>
> > That isn't really a useful operation in domain
> > decomposed methods. The useful operation is that I reduce different
> sized
> > received buffers into different (but sometimes overlapping) parts of
> my
> > local buffer.
> Well, the issue is that MPI reduction operations cannot be applied to
> vectors of different length because this would require the definition of
> an identity element. While this is easy for the predefined ops (e.g.,
> "MIN_INT" for int max and "0" for sum, etc.), this would require much
> more changes for user-defined operations (another call to specify
> these). The current interface proposal would require you to fill in
> those elements where needed. Or am I misunderstanding or missing something?
>
> > The single send buffer (with different datatype arguments) imposes no
> > restriction and is natural.
> Thanks!
>
> Best,
> Torsten
>
> --
> ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ -----
> Torsten Hoefler | Assistant Professor
> Dept. of Computer Science | ETH Zürich
> Universitätsstrasse 6 | Zurich-8092, Switzerland
> CAB E 64.1 | Phone: +41 76 309 79 29
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-coll/attachments/20121209/bfd047d9/attachment-0001.html>
More information about the mpiwg-coll
mailing list