MDSPAN - A Deep Dive Spanning C++, Kokkos & SYCL - Nevin Liber - CppCon 2022

---

MDSPAN - A Deep Dive Spanning C++, Kokkos & SYCL - Nevin Liber - CppCon 2022

This talk is a deep dive into the history behind MDSPAN (it’s roots being in Kokkos::View), the C++ standardization effort behind it (current status, various tradeoffs made over time, and language changes to help support it) and how SYCL is looking to leverage it in the future. MDSPAN is a non-owning multidimensional array reference, currently slated to be one of the flagship libraries added to C++23. View/reference vocabulary types first entered C++17 with string_view (a non-owning string reference), followed by span (a non-owning single dimension contiguous memory reference) and the ranges library. MDSPAN is the natural progression of this, and one that is critical to distributed (eg. CPU/GPU programming) and high-performance computing.

MDSPAN got its roots from Kokkos::View, One key difference between Kokkos::View & MDSPAN: Kokkos::View may be owning (reference-counted reference semantics) or non-owning. The former is also being standardized for C++26 as MDARRAY, although with value and not reference-counted semantics. Separately, in 2014 Microsoft proposed a similar type, array_view, be added to the standard. After a year and a half and seven revisions, it was ultimately abandoned in favor of what is now MDSPAN because it did not provide a zero-overhead abstraction.

The MDSPAN proposal itself has taken seven years and has been through 17 revisions (so far), with input from many different companies as well as the C++ Committee. What changed over the years and why did it change? In parallel, two key language changes were made which ultimately improved the interface: deprecating the comma operator inside square brackets, and the addition of the multidimensional subscript operator. This allows the natural syntax of a[I, j, k] instead of inferior alternatives like a(i, j, k), a[I][j][k] or even a[Index(i), j, k].
---

Nevin Liber

Nevin “:-)” Liber is a Computer Scientist in the ALCF (Argonne Leadership Computing Facility) division of Argonne National Laboratory, where he works on the oneAPI/DPC++/SYCL backend for Kokkos for Aurora. He also represents Argonne on the SYCL and C++ Committees, the latter as Vice Chair of LEWGI/SG18. Back when he started out working at Bell Labs over three decades ago, a friend of his called and asked “What do you know about C++? You folks invented it!” That was enough to get a relatively shy junior engineer to go find the local expert so he could go play with it, and the rest is history! He has worked in C++ across various industries and platforms (big data, low-latency, operating systems, embedded, telephony and now exascale computing, just to name a few). He has also been a C++ Committee member since 2010 and hosted both the C++ and C standards meetings in Chicago.
__

#cppcon #programming #cpp

[nickskywalker]

This is very exciting!
I am really enjoying seeing this included in the standard library as well as the proposal for graph algorithms and containers. A lot of great stuff on the table 😀

[miheervaidya]

Sadly I felt like this talk described the battle to get mdspan in spec/history of proposal than mdspan itself.

[AlfredoCorrea]

9:42 dynarray doesn’t need to store the allocator? How is it supposed to deallocate on destruction then? ( did it have a type erased deleter?)

[John-xlbx]

With the new variadic [] syntax, is adding array slice notation (ala Fortran, NumPy, Matlab) now a possibility down the road. Or is that not on the table?

[DerDoMeN]

One of the parts of C++ that I hate the most... Signed vs unsigned container/view/span size...

Use signed because unsigned has performance penalty...
But signed defines better the index - as you can only have items from 0 to N (where N is a positive number)... (and don't even get me started on the hate towards -1 meaning first item from the back that some languages implement...).
Yeah... But signed for less mistakes... So better (my headache grows)

I like compilers and all but I don't give a rat's ass that they have to sweat more if I can reason about code more easily.
I want the interface to say "there can only be signed numbers here" with the caveat: and if you assign a negative number I'll
- explode in your face at compile time
- whine/throw exception/whatnot in debug mode
- nasal daemons in release mode
What I want the generated code type to be: whatever is the fastest

ssize... I'd understand if it'd work the way I wrote above and mean "sane size"... But for ssize to mean signed size... Well... It just makes me angry...

p.s. And no... Contracts don't help as I'll still see a signed type as a return type and not "number<0, max(size_t), basic>" (basic as in non wrapping or whatnot), "sane_size_t" or shorter "ssize_t"...