Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CP013: Ensure the affinity proposal aligns with the mdspan proposal #69

Open
AerialMantis opened this issue Jul 30, 2018 · 4 comments
Open
Labels
SAN18 San Diego 2018 C++ Meeting

Comments

@AerialMantis
Copy link
Contributor

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.

@AerialMantis AerialMantis added the SAN18 San Diego 2018 C++ Meeting label Jul 30, 2018
@mhoemmen
Copy link
Collaborator

mhoemmen commented Sep 3, 2018

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
Copy link
Contributor Author

AerialMantis commented Sep 3, 2018

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
Copy link
Collaborator

mhoemmen commented Sep 6, 2018

@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
Copy link
Collaborator

mhoemmen commented Sep 6, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
SAN18 San Diego 2018 C++ Meeting
Projects
None yet
Development

No branches or pull requests

2 participants