Comparison with mdspan/mdarray

[xelatihy]

midspan and mdarray are being proposed for inclusion in the C++ standard library. Looking at this library, it seems that some of the basic concerns are the same, but the proposed model and solution is different. It would be very helpful for users that are deciding about which low-level type to use to have a comparison between the two approaches.

[dsharlet]

Thanks for the good suggestion. I think this deserves e.g. a README section, but I'm not sure I have a strong enough understanding of mdspan and mdarray at this point for that. Here's my current thinking, please correct me if you know better!

Basic multi-dimensional array storage and access

• mdspan looks like it is less flexible, and similarly easy to use, than array_ref.
• basic_mdspan looks more flexible, but more verbose to use, than array_ref.

I think that as long as your LayoutPolicy is an affine mapping, and isn't a trivial shape type, this library will be easier to use. But LayoutPolicy can be anything, so basic_mdspan is more flexible, if you need something like tiled or other non-affine shapes.

The one significant thing I've noticed: it appears that layout_strides doesn't support compile-time constant strides, which is really critical for the stride 1 dimension at least. https://github.com/kokkos/mdspan#caveats mentions this as the first caveat. Hopefully the mdspan that becomes standard fixes this...

It's hard to compare mdarray because a lot of the detail is missing from the proposal, and I can't find an implementation to look at (like https://github.com/kokkos/mdspan), particularly tests can be very helpful (though TBH, I haven't found as many mdspan tests as I'd like).

It looks like the current design of mdarray is to own a "flat" container like std::vector (the ContainerPolicy). I started with a similar design, but found it to have some issues and ended up going with what I have now, which is array doing its own memory management with an std::allocator-like allocator object. To be honest, I'm struggling to remember exactly why I ended up giving up on the flat container approach. Part of it may have been what happens when shapes have padding, and there are elements in the array that are unaddressable by the shape (what these tests cover).

Higher-level algorithms

This library provides some higher level algorithms and tools that are integrated with the array types. I think the mdspan and mdarray proposals probably consider these things to be out of scope. Some examples are:

• for_all_indices and for_each_index: without these, it's hard to write rank-agnostic algorithms.
• split<>: This allows splitting and tiling loops easily and "transparently".
• Helpers for accessing arrays in ways that are order agnostic (for_each_value and copy), that can really significantly optimize some kinds of tasks. Some examples are covered by these performance tests.
• Einstein reductions.

I think most of these could be implemented on top of mdspan, but there are some issues. For example, I can't see how to create a subspan with a constexpr extent, which is really a key part of tiling loops efficiently. This is why interval<> in this library is (unfortunately necessarily) represented [begin, begin + extent) instead of [begin, end).

Non-zero mins being part of the shape are also very helpful for tiling. Of course, the mins can be passed separately, but now it's not "transparent" tiling any more. But at the same time, people might prefer the numpy style slicing rather than the style this library uses (#24).