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