cuda::std::vector support

[ikitayama]

@brycelelbach I’m wondering as to when it will be implemented in libcu++. A roughy time frame would be appreciated.

[brycelelbach]

Can you elaborate on what you mean?

You want a std::vector that can be used in device code (e.g. does device side allocation)? Or do you want a std::vector that you use in host code, but that allocates unified memory? Or one that allocates device only memory?

@wmaxey can comment further based on your response.

[ikitayama]

Hi Bryce.
I want a std::vector that I use in host code, but that allocates unified memory. That way, I don't need to create an array from a std::vector when entering the OpenMP target region.

[ikitayama]

I've been trying to offload an OpenMP app written in C++.

[wmaxey]

It's possible that in the future we could implement a cuda::vector, but it would be an extension and likely encroaches on what is available from Thrust today.

Is there any particular reason that Thrust's vectors are not useful for your case? If you can provide a good reason, it would be something we could take into account when designing what a std::vector extension might need to be sufficiently different from Thrust's.

[ikitayama]

In my understanding, we can not create a Thurst's vector that can be accessed both from host and device. That's why I wonder when cuda::vector will be implemented in libcu++.

[wmaxey]

I believe Thrust has this thrust::universal_vector, I'm unsure if it's pinned or managed memory, but documentation claims that it is accessible by both host and device.

@brycelelbach any gotchas?

[brycelelbach]

thrust::universal_vector is unified memory (e.g. managed). It's exactly what you want.

[ikitayama]

Thank you both @brycelelbach @wmaxey ! I did not know the "universal" version, however, if I deploy it that means a significant rewrite of C++ code. I am concerned about it, and makes it un-portable, and maintenance cost.