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

[Jeff Hammond]

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 <bwbarre at sandia.gov> wrote:
> 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
>
>
>
>
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma



-- 
Jeff Hammond
jeff.science at gmail.com