You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: P0009/wg21/data/index.yaml
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -104768,7 +104768,7 @@ references:
104768
104768
- family: Mark Hoemmen, Daisy Hollman, Christian Trott, Daniel Sunderland, Nevin Liber, Alicia Klinvex, Li-Ta Lo, Damien Lebrun-Grandie, Graham Lopez, Peter Caday, Sarah Knepper, Piotr Luszczek, Timothy Costa
104769
104769
issued:
104770
104770
year: 2023
104771
-
URL: https://wg21.link/p1673r1
104771
+
URL: https://wg21.link/p1673r13
104772
104772
- id: P1674R0
104773
104773
citation-label: P1674R0
104774
104774
title: "Evolving a Standard C++ Linear Algebra Library from the BLAS"
<p>C++23 introduced <code>mdspan</code> (<spanclass="citation" data-cites="P0009R18">[<ahref="#ref-P0009R18" role="doc-biblioref">P0009R18</a>]</span>), a nonowning multidmensional
468
+
<p>C++23 introduced <code>mdspan</code> (<spanclass="citation" data-cites="P0009R18">[<ahref="#ref-P0009R18" role="doc-biblioref">P0009R18</a>]</span>), a non-owning multidmensional
469
469
array abstraction that has a customizable layout. Layout customization
470
470
was originally motivated in <spanclass="citation" data-cites="P0009R18">[<ahref="#ref-P0009R18" role="doc-biblioref">P0009R18</a>]</span> with considerations for
471
471
interoperability and performance, particularly on different
that represent the span of the <code>mdspan</code>. Additionally, it’s
488
488
not entirely clear what this would entail.
489
489
<code>std::linalg::copy</code> (<spanclass="citation" data-cites="P1673R13">[<ahref="#ref-P1673R13" role="doc-biblioref">P1673R13</a>]</span>) is limited to
490
-
<code>mdspans</code> of rank 2 or lower.</p>
490
+
<code>mdspan</code>s of rank 2 or lower.</p>
491
491
<p>Moreover, the manner in which an <code>mdspan</code> is copied (or
492
492
filled) is highly performance sensitive, particularly in regards to
493
-
caching behavior when traversing mdspan memory. A naïve user
494
-
implementation is easy to get wrong in addition to being tedious for
495
-
higher rank <code>mdspan</code>s. Ideally, an implementation would be
496
-
free to use information about the layout of the <code>mdspan</code>
493
+
caching behavior when traversing <code>mdspan</code> memory. A naive
494
+
user implementation is easy to get wrong in addition to being tedious
495
+
for higher rank <code>mdspan</code>s. Ideally, an implementation would
496
+
be free to use information about the layout of the <code>mdspan</code>
497
497
known at compile time to perform optimizations; e.g. a continuous span
498
-
<code>mdspan</code> copy for trivial types could be implementeed with a
498
+
<code>mdspan</code> copy for trivial types could be implemented with a
499
499
<code>memcpy</code>.</p>
500
500
<p>Finally, providing these generic algorithms would also enable these
501
501
operations for types that are representable by <code>mdspan</code>. For
502
502
example, this would naturally include <code>mdarray</code>, which is
503
503
convertible to <code>mdspan</code>, or for user-defined types whose view
504
-
of memory corresponds to <code>mdspans</code> (e.g. an image class or
504
+
of memory corresponds to <code>mdspan</code>s (e.g. an image class or
Copy file name to clipboardExpand all lines: mdspan_copy/mdspan_copy.md
+16-8Lines changed: 16 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,15 +14,15 @@ author:
14
14
15
15
# Motivation
16
16
17
-
C++23 introduced `mdspan` ([@P0009R18]), a nonowning multidmensional array abstraction that has a customizable layout. Layout customization was originally motivated in [@P0009R18] with considerations for interoperability and performance, particularly on different architectures. Moreover, [@P2630R4] introduced `submdspan`, a slicing function that can yield arbitrarily strided layouts. However, without standard library support, copying efficiently between mdspans with mixes of complex layouts is challenging for users.
17
+
C++23 introduced `mdspan` ([@P0009R18]), a non-owning multidmensional array abstraction that has a customizable layout. Layout customization was originally motivated in [@P0009R18] with considerations for interoperability and performance, particularly on different architectures. Moreover, [@P2630R4] introduced `submdspan`, a slicing function that can yield arbitrarily strided layouts. However, without standard library support, copying efficiently between `mdspan`s with mixes of complex layouts is challenging for users.
18
18
19
19
Many applications, including high-performance computing (HPC), image processing, computer graphics, etc that benefit from `mdspan` also would benefit from basic memory operations provided in standard algorithms such as copy and fill. Indeed, the authors found that a copy algorithm would have been quite useful in their implementation of the copying `mdarray` ([@P1684R5]) constructor. A more constrained form of `copy` is also included in the standard linear algebra library ([@P1673R13]).
20
20
21
-
However, existing standard library facilities are not sufficient here. Currently, `mdspan` does not have iterators or ranges that represent the span of the `mdspan`. Additionally, it's not entirely clear what this would entail. `std::linalg::copy` ([@P1673R13]) is limited to `mdspans` of rank 2 or lower.
21
+
However, existing standard library facilities are not sufficient here. Currently, `mdspan` does not have iterators or ranges that represent the span of the `mdspan`. Additionally, it's not entirely clear what this would entail. `std::linalg::copy` ([@P1673R13]) is limited to `mdspan`s of rank 2 or lower.
22
22
23
-
Moreover, the manner in which an `mdspan` is copied (or filled) is highly performance sensitive, particularly in regards to caching behavior when traversing mdspan memory. A naïve user implementation is easy to get wrong in addition to being tedious for higher rank `mdspan`s. Ideally, an implementation would be free to use information about the layout of the `mdspan` known at compile time to perform optimizations; e.g. a continuous span `mdspan` copy for trivial types could be implementeed with a `memcpy`.
23
+
Moreover, the manner in which an `mdspan` is copied (or filled) is highly performance sensitive, particularly in regards to caching behavior when traversing `mdspan` memory. A naive user implementation is easy to get wrong in addition to being tedious for higher rank `mdspan`s. Ideally, an implementation would be free to use information about the layout of the `mdspan` known at compile time to perform optimizations; e.g. a continuous span `mdspan` copy for trivial types could be implemented with a `memcpy`.
24
24
25
-
Finally, providing these generic algorithms would also enable these operations for types that are representable by `mdspan`. For example, this would naturally include `mdarray`, which is convertible to `mdspan`, or for user-defined types whose view of memory corresponds to `mdspans` (e.g. an image class or something similar).
25
+
Finally, providing these generic algorithms would also enable these operations for types that are representable by `mdspan`. For example, this would naturally include `mdarray`, which is convertible to `mdspan`, or for user-defined types whose view of memory corresponds to `mdspan`s (e.g. an image class or something similar).
26
26
27
27
## Safety
28
28
@@ -47,19 +47,27 @@ We settled on `<mdspan>` because as proposed this is a relatively light-weight a
47
47
48
48
## Existing `copy` in `std::linalg`
49
49
50
-
[@P1673R13] introduced several linear algebra operations including `std::linalg::copy`. This operation only applies to `mdspan`s with $rank \le 2$. This paper is proposing a version of `copy` that is constrained to a superset of `std::linalg::copy`.
50
+
[@P1673R13] introduced several linear algebra operations including `std::linalg::copy`. This operation only applies to `mdspan`s with $rank \le 2$. This paper is proposing a version of `copy` that is not constrained by the number of ranks and differs from `std::linalg::copy` in some important ways outline below.
51
51
52
-
Right now the strict addition of `copy` would potentially cause the following code to be ambiguous, due to ADL-finding `std::copy`:
52
+
Note that right now the strict addition of `copy` would potentially cause the following code to be ambiguous, due to ADL-finding `std::copy`:
53
53
54
54
```c++
55
55
using std::linalg::copy;
56
56
copy(mds1, mds2);
57
57
```
58
58
59
-
One possibility would be to remove `std::linalg::copy`, as it is a subset of the proposed `std::copy`, though as of now this paper does not propose to do this.
59
+
One possibility would be to remove `std::linalg::copy`, as it is a subset of the proposed `std::copy`. This was rejected by the paper authors because of certain requirements in \[linalg.reqs.alg\] -- that is:
60
+
61
+
> The function may make arbitrarily many objects of any linear algebra value type, value-initializing or direct-initializing them with any existing object of that type.
62
+
63
+
This requirement is likely undesirable for a generalized copy algorithm.
64
+
65
+
There is a similar argument against simply generalizing `std::linalg::copy`. In addition to the freedom of `std::linalg::copy` to arbitrarily value or direct-initializing values, using the linear algebra version of copy would require the use of unnecessary includes and namespaces. It seems not very ergonomic for a user to have to use `std::linalg::copy` and include `<linalg>` even if the `mdspan` operations they are performing are unrelated to linear algebra.
60
66
61
67
## What the proposal does not include
62
68
69
+
There are a few additions that are analogous to existing standard algorithms that are not included in this proposal, both to keep the proposal small and because some of these algorithms do not make sense in the context of `mdspan`s:
70
+
63
71
* `std::move`: Perhaps this should be included for completeness's sake. However, it doesn't seem applicable to the typical usage of `mdspan`.
64
72
* `(copy|fill)_n`: As a multidimensional view `mdspan` does not in general follow a specific ordering. Memory ordering may not be obvious to calling code, so it's not even clear how these would work. Any applications intending to copy a subset of `mdspan` should use call `copy` on the result of `submdspan`.
65
73
* `copy_backward`: As above, there is no specific ordering. A similar effect could be achieved via transformations with a custom layout, similar to `layout_transpose` in [@P1673R13].
@@ -70,7 +78,7 @@ One possibility would be to remove `std::linalg::copy`, as it is a subset of the
70
78
```c++
71
79
template<class SrcElementType, class SrcExtents, class SrcLayoutPolicy, class SrcAccessorPolicy,
72
80
class DstElementType, class DstExtents, class DstLayoutPolicy, class DstAccessorPolicy>
0 commit comments