Provide specialization of AccessTraits for std::vector

[aprokop]

This PR provides a specialization of AccessTraits for std::vector for user convenience.

In general, we should document somewhere that we reserve the right to provide those specializations for something user's don't control in their libraries (like, things from std::). If users want to provide custom specializations for those, they should wrap inside a holder.

[dalg24]

Not sure it is a good idea

[Rombur]

Not sure it is a good idea

When updating the wrappers for deal.II, we realized that there is a lot of boiler code to write with the new interface. It makes it unnecessary hard to use ArborX. With ArborX 1.X, we only needed to write access_traits. Now to do the same thing, we need to write an ExtractIndex structure, the acces_traits, and the IndexableGetter. For most people, only the IndexableGetter uses user data.

[aprokop]

Not sure it is a good idea

What do you see as the difference between Kokkos::View and std::vector specializations?

[dalg24]

Views are fit for accelerators. What would we want to do about host device annotations on the access functions?

[aprokop]

What would we want to do about host device annotations on the access functions?

Not use them. Everything will be HostSpace, so we won't need annotations.

[dalg24]

It is not about what memory space we tag it with, we'd run into issues when CUDA or HIP are enabled.
Also, I am not sure how it interacts with NVHPC when stdpar is enabled.

[Rombur]

It is not about what memory space we tag it with, we'd run into issues when CUDA or HIP are enabled.

Why? It worked correctly with the previous API. I have been doing that for years in adamantine.

[aprokop]

After a long hiatus, I'm coming back to this PR.

Also, I am not sure how it interacts with NVHPC when stdpar is enabled.

My understanding is that when using nvc++ compiler with -stdpar=gpu option, it replaces the default std::allocator with a managed memory allocator. In that case, the data lives in the Unified Memory space, and migrates based on page faults.

For hip, with --hipstdpar, it can use HMM.

I think in either case, the memory would be migrated to the host if we access it there. If we run into issues later, we could do cudaPointerGetAttributes to check where the pointer lives.

It is not about what memory space we tag it with, we'd run into issues when CUDA or HIP are enabled.

@dalg24 Can you please elaborate? I don't understand what you mean here.

[dalg24]

AccessTraits::get defined as a host-only function that will be called from a host device function.

[aprokop]

AccessTraits::get defined as a host-only function that will be called from a host device function.

It will result in a warning, yes, but in a correct execution, as the corresponding hierarchy will be on the host.

[aprokop]

@dalg24 requested that we produce no warning in this scenario. Will need to see how we can hide it.