Memset takes non-const reference to view

[chillenzer]

Hi, I've just spent way too long deducing the subtleties of calling alpaka::memset: Down in the GPU path, the function CreateTaskMemset::createTaskMemset(TView&, ...) takes its view by NON-const reference. This implies that it cannot bind to rvalue views. That bit me in a call like

alpaka::memset(..., alpaka::createView(...), ...);

with the very vague error message

no instance of function template ... matches argument list ...

(now find that one & and realise that precisely that one tries to bind to an rvalue).

I think that interface is semantically not quite correct. The view is kept constant during the execution of the function. It's the underlying memory that changes, i.e., we should have something like TView<non-const TElem> const& (although specifying that without C++20 concepts is probably non-trivial).

I would suggest to either change to const& or at least find a way to provide a helpful error message.

[psychocoderHPC]

I am not sure if we only call constant methods of the view.

[chillenzer]

From what I see in the linked file, it's all getters of some form. And semantically I would be very surprised if there's a (not-by-oversight) non-const use in there. As it first failed on the linked line and not at all on CPU, I think you'd only have to check the top of that file.

[fwyzard]

I think the issue is if we think a view and a buffer should behave like a container (e.g. a vector) or like pointer (e.g. a shared_ptr).

With a vector<T> const& one cannot modify the content of the vector.

With a shared_ptr<T> const& one can modify the content of the pointed-to object.

With an alpaka view, a const& prevents some of the operations, but one can always make a non-const copy of the view and use that to modify the content of the original data.

So, currently views and buffers behave more like a pointer. If we agree that this is the expected behaviour, we should indeed change alpaka::memset to take a const& (and document this somewhere).

[chillenzer]

Very well analysed! I fully agree!

In my interpretation of the English language, "View" feels like a very pointer-like thing but I know that a Buffer has more aspects of a container (at least in alpaka). Considering the words only, I might have gone as far as drawing the dividing line between the two but I'm not sure if that would be practical (e.g. "Is a buffer a view?" and the like).

Edit: PS: I think I would rather compare a view to a std::span. What's the semantics there?

[fwyzard]

Yes, an alpaka buffer implements the view interface, so it is a view and can be used with memcpy, memset, etc.

To add some confusion, std::vector and std::array also implement the view interface, even though they have a different semantic :-/