Re: [mpi3-coll] Neighborhood collectives round 2: reductions

11 Dec 2012


      On Sun, Dec 09, 2012 at 04:55:51PM -0800, Jed Brown wrote:
...
Understood. May I ask what is the application motivating this routine?
For the neighbor_reduce, the use-case follows from your earlier emails
(you asked explicitly for this on the collectives mailinglist in
CAM9tzSmY38bq3gmYqwB5TS5jOv8uwTU9e526tANHDTYgX4XOBg@mail.gmail.com). The
neighbor_reducev is a simple generalization and gets closer to what you
were asking for. I think it's non-trivial to provide identity elements
in the interface while it's not too hard to just put the data into the
function (and hopefully not too much overhead).
If you now think there is no use-case for any of those (or both)
functions then we should discontinue the discussion of them (I have
absolutely no problem with this :-).

Best,
  Torsten
...
On Dec 9, 2012 1:14 PM, "Torsten Hoefler" <[1][email protected]> 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][2][email protected]>
     > ï¿½ ï¿½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][3]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. [4]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 ------------- [5]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: [6]+41 76 309 79 29
References
Visible links
   1. mailto:[email protected]
   2. mailto:[email protected]
   3. http://www.unixer.de/sec/topol.pdf
   4. http://www.unixer.de/sec/topol.pdf
   5. http://www.unixer.de/
   6. file:///home/htor/tmp/mutt/tel:%2B41%2076%20309%2079%2029
-- 
### 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

Torsten Hoefler

tags

participants (1)