It doesn’t break backward compatibility. The info argument is still useful when you don’t want to use replace. I don’t see anything wrong with it. On Mar 10, 2014, at 11:01 PM, Jeff Hammond <[email protected]> wrote:
Does this or does this not break BW compatibility w.r.t. MPI-2.2 and did we do it intentionally? Unless we did so intentionally and explicitly, I will argue that the WG screwed up and the info key+val is invalid.
Jeff
On Mon, Mar 10, 2014 at 11:03 PM, Balaji, Pavan <[email protected]> wrote:
If a hardware can implement MPI_SUM, it should be able to implement MPI_SUM with 0 as well.
But that’s not a generic solution.
Jeff: at some point you were planning to bring in a ticket which does more combinations of operations than just same_op and no_op. Maybe it’s worthwhile bringing that up again?
— Pavan
On Mar 10, 2014, at 9:26 PM, Jim Dinan <[email protected]> wrote:
Maybe there's a loophole that I'm forgetting?
On Mon, Mar 10, 2014 at 9:43 PM, Jeff Hammond <[email protected]> wrote: How the hell can I do GA or SHMEM then? Roll my own mutexes and commit perf-suicide?
Jeff
Sent from my iPhone
On Mar 10, 2014, at 8:32 PM, Jim Dinan <[email protected]> wrote:
You can't use replace and sum concurrently at a given target address.
~Jim.
On Mon, Mar 10, 2014 at 4:30 PM, Jeff Hammond <[email protected]> wrote: Given the following, how do I use MPI_NO_OP, MPI_REPLACE and MPI_SUM in accumulate/atomic operations in a standard-compliant way?
accumulate_ops — if set to same_op, the implementation will assume that all concurrent accumulate calls to the same target address will use the same operation. If set to same_op_no_op, then the implementation will assume that all concurrent accumulate calls to the same target address will use the same operation or MPI_NO_OP. This can eliminate the need to protect access for certain operation types where the hardware can guarantee atomicity. The default is same_op_no_op.
We discuss this before and the resolution was not satisfying to me.
Thanks,
Jeff
-- Jeff Hammond [email protected] _______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
_______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
_______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
_______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
_______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
-- Jeff Hammond [email protected] _______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma