search

kokkos / mdarray

Other
10 stars 9 forks source link

P1684: Consider changing proposal not to require storing a pointer in mdarray #10

Closed mhoemmen closed 2 years ago

mhoemmen commented 2 years ago

An important use case for mdarray is small arrays that users would normally pass around by value. For example, 3x1, 4x1, 3x3, or 4x4 arrays of very small integer or floating-point types are common in computer graphics. Such arrays might be small enough to fit in a pointer, so storing an explicit pointer to the data in mdarray (e.g., by storing an mdspan inside the mdarray) might cost enough to make mdarray undesirable for these applications.

Acceptance criteria:

  1. An mdarray with entirely compile-time extents, and suitable layout and accessor types, should take no more storage space than an std::array<T, N>, where T is the element type and N is the product of the extents.
  2. It should be possible to express overaligned access of types (e.g., 4*sizeof(T) for a 4x1 array of T) with entirely compile-time extents. It's OK if this requires a custom accessor, but it must not require additional storage (see (1)).
nliber commented 2 years ago

That would make mdarray a "sometimes owning" class (sometimes reference semantics, sometimes value semantics), which is harder to reason about (and a harder sell for the committee).

A similar argument was made (possibly only informally) when something like Boost.CallTraits param_type was discussed, but that ultimately went nowhere.

Brainstorming: We might need to provide both: an adaptor that only has reference semantics, and an adaptor that allows value semantics for "small" types (which opens up the question of whether or not to allow users to customize what is meant by "small" type).

mhoemmen commented 2 years ago

@nliber wrote:

That would make mdarray a "sometimes owning" class (sometimes reference semantics, sometimes value semantics), ....

Oh wait, woah, I definitely didn't mean to imply that. Sorry if I didn't explain it clearly.

mdarray would always have a container in it; it would always act like a container. It's just that I don't think mdarray needs to store an mdspan or a pointer. The pointer can be constructed on the fly as needed for the accessor (acc_(container_.data(), offset)).

crtrott commented 2 years ago

this is getting eliminated by my rewrite which gets rid of ContainerPolicy.

mhoemmen commented 2 years ago

R1 (and R2 after it) both fix this issue. mdarray stores a container, not a pointer. It has a conversion method to get the viewing mdspan.