Grid operations feedback

[Dan Bonachea]

8.2 Array Construction and Destruction: "The user may specify an alternative allocator F to use instead of the default, which must be a function of type void ()(size_t)"

Why does this use a different allocator signature than upcxx:allocate()? Is it possible to allocate a grid on a remote rank? (must one use the experimental "array over user-provided memory" support for this?)

8.3: "The expression A.copy(B) ... is illegal if A and B do not have the element type and arity."

There's an important missing word in this sentence. Do we require type equality? Or can we allow compatible types (eg for grids of pointers to objects)?

8.3: A.slice(k; j) produces the grid, B, with domain A.domain().slice(k) such that B[...] = A[...]. It is an error if any of the index points used to index A are not in its domain, or if A.arity <= 1."

The "=" should probably be "aliases", to clarify this is an array view creation and not an allocate-and-copy operation. Also, it should probably read "if A.arity == 1" (as there are no arrays with arity < 1).

8.4.2: "The layout of a newly constructed array is described in x8.2, enabling manual indexing to be safely performed on such arrays. For a remapped grid, the user must manually determine the locations of its data based on the layout of the original grid."

Does this mean that library writers (who are writing on top of UPC++) can never safely perform manual indexing on a grid passed in by their users? Or will their users be forced to pass in (redundant) array layout information to permit this implementation option? This manual indexing feature argues for query functions that a callee can use to retrieve the layout metadata from an arbitrary grid.

[Amir Kamil]

8.2: No, it is currently not possible to allocate a grid on a remote rank. In the future, we may support this. It is also not possible to destroy a remote grid. (Both operations require initializing or destroying individual elements, which can only be done on the remote rank itself. It is possible to implement this using asyncs, but it would be inefficient, so I don't think we should do so unless we have a motivating example where it makes sense.)

8.3a: It should be "... is illegal if A and B do not have the same element type and arity." I think we might get ourselves into trouble if we loosen this restriction. In particular, how do we define "compatible?" If A has element type int64_t and B has element type int32_t, then the operation makes sense, but it would be a pain to implement. Pointer types might lead us into a situation similar to Java's ArrayStoreException. So for now, I think it makes sense to restrict the operation to equivalent types.

8.3b: What do you think about replacing it with "&B[...] == &A[...]?" And I agree that it should be "A.arity == 1."

8.4.2: At the moment, users must pass in redundant array layout information. I think it makes sense to provide query operations, but I think we should leave that for a future version of the spec.

[Amir Kamil]

I move that we close this issue, as it is not relevant to v1.0.