On Aug 18, 2016, at 12:44 AM, Gilles Gouaillardet <gil...@rist.or.jp> wrote: > > when reading the dev meeting minutes, i saw MPI_Reduce_local was discussed > and might be moved to the coll framework, > > and here are my 0.02 US$ : > > > the prototype of MPI_Reduce_local is > > int MPI_Reduce_local(const void *inbuf, void *inoutbuf, int count, > MPI_Datatype datatype, MPI_Op op) > > > bottom line, this is not a collective operation, so that could explain why it > is not part of the coll framework.
Agreed. As always, the minutes shows a summary, but not the whole conversation. Let me try to provide a little more color on this particular conversation... (please feel free to ask about other meeting minutes items!) In the meeting, I cited two reasons why it wasn't in coll: 1. It's not collective (as you noted). :-) 2. It's just a simple call to the underlying op framework. The rationale for moving it to the coll framework was for IBM / Spectrum MPI (the successor to IBM Platform MPI): 1. They have a proprietary PML component 2. They have a proprietary coll component In all the SMPI PML and coll calls, they do some advanced GPU buffer handling, which basically means that all MPI_* API calls for p2p and collectives get this advanced GPU buffer handling. ...but MPI_REDUCE_LOCAL isn't handled by the pml or coll frameworks. It would be nice / convenient if they could just add REDUCE_LOCAL to coll, and therefore add their advanced GPU buffer handling to their existing coll component (vs. hacking up ompi/mpi/c/reduce_local.c). We talked about it in the meeting: admittedly, moving REDUCE_LOCAL to coll is a little weird / the rationale is a bit weak. But no one had a strong opinion here (i.e., no one felt this was "bad"; it's just "weird"), and no one had a better idea. So we said, "Sure, go ahead." That being said, alternative suggestions would be welcome. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
