I created https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/399 to track this. Jeff On Thu, Oct 24, 2013 at 2:45 PM, Barrett, Brian W <[email protected]> wrote:

On 10/24/13 1:24 PM, "Jeff Hammond" <[email protected]> wrote:

...

...

I would have no objection to adding yet another info key. I think if we keep at this for another year, we can make sure we have the longest pre-defined info key in the spec.

Or we can focus on the values. Instead of "same_op_no_op_replace = true" we can have "op_list = no_op,replace,sum" and let the implementation instantiate same_op_no_op_replace on its own.

The advantage here would be that if the bad thing is FP divide, I can list no_op,sum,replace,max,min and still have goodness. The disadvantage would be all the test to list the options. So maybe long true/false keys have some advantage.

...

...

I admit to having very little medium term memory; which is the type-homogeneity suggestion?

Medium-term meaning in the last 2 hours? :-)

Fine, no memory at all.

...

It addresses the lack of type-specification in MPI window creating. If I can say at window allocation time that I only want to use MPI_INT, then maybe the implementation can avoid a software implementation that might be required if I was to use MPI_FLOAT, for example. In my experience, NICs are more likely to support fixed-point arithmetic in hardware than floating-point.

As an info key? I think that would be helpful for exactly the reason you said. If I know the user isn't going to use long double complex data types, that makes life a bit easier :).

Brian

-- Brian W. Barrett Scalable System Software Group Sandia National Laboratories

_______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

-- Jeff Hammond [email protected]