CP013: Ensure the affinity proposal aligns with the mdspan proposal

[AerialMantis]

trafficstars

It was raised at the Rapperswil meeting that the proposal for mdspan (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0009r7.html) also provides mechanisms for specifying how memory is laid out and that we should ensure that the affinity proposal aligns with this.

[mhoemmen]

In theory, Layout [mdspan.layout] and Accessor [mdspan.accessor] should already let mdspan map from indices to an unusual memory space, such as PGAS (partitioned global address space) or memory manually segmented by NUMA affinity region. We've used something like this to write "segmented" vectors, that have a two-level mapping from a contiguous index range to a noncontiguous sequence of "chunks" of contiguous memory.

The mdspan constructor that takes a span breaks this generalization a bit, since it requires initialization of Accessor::pointer from span::data(), a raw pointer. I'll have to go look at the latest revisions to see if folks want to fix that bit, or if they would prefer requiring constructibility of pointer from a raw pointer.

[AerialMantis]

Notes from 2018-09-03 call:

• mdspan is multi-dimensional, span is single dimensional.
• mdspan is a view, so doesn't perform allocation, but can be owning or non-owning depending on the pointer that it is constructed from.
• Access::pointer doesn't have to be a raw pointer, it can be for example atomic or some kind of fancy pointer.
• We don't see any issues with the affinity proposal aligning with mdspan, it should be able to suitably represent the properties we want to expose.
• We may have to think some more about how the properties of the memory resource are propagated through the allocated to an mdspan, we probably don't want the allocator to return an mdspan, that's maybe too high-level.
• It is the intention that mdspan be constructible from other non-standard pointer types.

@mhoemmen thanks very much for the summary, that's very helpful.

[mhoemmen]

@AerialMantis The latest version of the P0009 proposal, and the reference implementation, live here:

https://github.com/ORNL/cpp-proposals-pub/tree/master/P0009

Christian tells me that they got rid of the mdspan constructors that take a span, specifically so that would not require conversion of a raw pointer to Accessor::pointer. He further says: "You still need a decay function to get a element_type* out of a pointer but we discussed making that optional."

[mhoemmen]

Just to clarify: mdspan is a non-owning view of an existing contiguous range of elements. Indexing may be noncontiguous, but the underlying memory must be contiguous. Christian would prefer to keep that requirement for now, and discuss relaxing it as a later TS. I can see the value of deferring the "let's relax the 'valid range' definition to handle weird memory not accessible from the host CPU" discussion ;-) .

My guess is that mdspan implementations would not depend on this requirement for nondefault Accessor types. In practice, this should permit (otherwise) conforming implementations to add the necessary function attributes (e.g., __device__ __host__ for CUDA) and to wrap memory that's not necessarily accessible from host.