[mpiwg-rma] [EXTERNAL] Re: same_op_no_op and SHMEM

[Barrett, Brian W]

On 10/24/13 1:24 PM, "Jeff Hammond" <jeff.science at gmail.com> 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