[mpich-discuss] Indexed MPI_Reduce_local

[Jed Brown]

On Wed, Jan 2, 2013 at 11:35 AM, Dave Goodell <goodell at mcs.anl.gov> wrote:

> > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/318
>
> I actually did a bunch of work in a private branch to support these types,
> but stopped short of finishing it when the overall Forum opinion on them
> turned rather sour.  Perhaps we should restart the effort on this (both
> standardization and implementation) now that MPI-3.0 is out.
>

I actually think they shouldn't be standardized, but instead, user-defined
types should be restored to first-class status like they were in MPI-1. ;-)

But as long as the Forum remains heavily committed to discriminating
against user-defined types, I'd like to find a way to support them.

> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/319
>
> I don't have any objection to these types, they just need to be
> implemented.  We can put them in as MPIX_ types for now.
>
> > Any other suggestions?
> >
> > In lieu of a more elegant solution, I'm going to match on the types and
> ops that I need to support and write the sparse reduction by hand.
> >
> > In the longer term, I'm curious whether the MPICH developers, and
> eventually the Forum, may be interested in providing better support for
> higher level comm libraries like this.
>
> Like motherhood and apple pie, of course the answer is yes :)  The devil
> is always in "to what extent".
>

I finished re-implementing my "SF" comm component over plain Isend/Irecv so
that all the types I need work without any extras from MPI. My API still
accepts MPI_Datatype and MPI_Op, and I'd eventually like it to support all
combinations (including user-defined types and ops defined by the caller,
but that I didn't have prior knowledge of) over all backends (one-sided,
basic two-sided, and (soon) neighborhood collectives). In principle, there
would be good reasons to use different backends in different contexts
because they have different setup vs. execution costs, and different
tradeoffs associated with packing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20130102/7e910865/attachment.html>