-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
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 |
Notes from 2018-09-03 call:
@mhoemmen thanks very much for the summary, that's very helpful. |
@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 |
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 |
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.
The text was updated successfully, but these errors were encountered: