On Wed, Jan 2, 2013 at 11:35 AM, Dave Goodell <[email protected]> wrote:
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.