[QST] Plan on interoperability with thrust and libcu++.

[ZhenshengLee]

First I'd like to say that's a great job.

This repo is a api wrapper with modern cpp style. And modern cpp is about not only classes, namespaces, but also containers and STL algorithms, even with OS resource management.

Thrust by NVIDIA has provided abstractions of resource management and some stl algorithms in modern cpp way, so how can we developers make the best use of both of this repo and thrust, in an maintained repo, for example, like cupoch.

Thanks.

[eyalroz]

@ZhenshengLee - Remember the scope of this repository is to simply wrap the CUDA (runtime and other) APIs - not to provide other functionality or higher-level abstractions.

Thrust by NVIDIA has provided abstractions of resource management and some stl algorithms in modern cpp way

Personally I am underwhelmed by thrust's choice of abstractions. It's somewhat anti-modular and non-cooperative with other libraries. (Caveat: Haven't given it a thorough look in a couple of years.)

so how can we developers make the best use of both of this repo and thrust,

Well, it's not trivial to use thrust with the CUDA Runtime API (and other APIs like the driver API etc.), and for the same reason it is somewhat difficult to use it with my API wrappers... but no more difficult. That is, whatever you were doing with thrust + CUDA APIs, you can now do at least as easily with my wrappers.

I would also advise you to consider carefully whether you are not paying a significant performance price by using thrust. In some case, you are likely to be.

... with all that being said, however - if there is a concrete suggestion which you believe would help use these wrappers with thrust, I will definitely consider it.

[ZhenshengLee]

I would also advise you to consider carefully whether you are not paying a significant performance price by using thrust. In some case, you are likely to be.

Thanks for your quick reply.

Is there any performance decreasement report with thrust comparing to cuda runtime api? I have googled it but could not find any info.

I think the performance price you mentioned is just like using STL in c++, which could be benificial for building large and complicated software in a safer/easier way.

I will have a try to intergrate this wrapper into a larger cuda project.

Edit: I think this is a objectively comment on thrust, see stackover flow on thrust

[eyalroz]

Is there any performance decreasement report with thrust comparing to cuda runtime api? I have googled it but could not find any info.

The two can't be compared... thrust offers a lot of concrete functionality. Some of it is just fine and (probably) optimal, some of it has overheads. My API wrappers don't offer any concrete functionality - just a different way of using CUDA's APIs. So it's the difference between writing your own kernels with your own data structures vs. using thrust.

I think the performance price you mentioned is just like using STL in c++,

Not quite. For example, with the STL, you don't have to use std::vector for everything; with thrust, you are basically stuck with their "device vectors". etc.

which could be benificial for building large and complicated software in a safer/easier way.

Depends on which part of the STL. The type traits, utility classes etc. - sure. But if you use std::unordered_map for example you'll pay a heavy price.

Not to mention how taking some of the STL prevents you from taking the rest: Its data structures are not friendly with std::optional and std::expected, since they were designed much earlier.

[eyalroz]

Also, you might be interested in taking a look at my cuda-kat repository, which offers some tools for kernel authors that you can pick-and-choose from, and aren't opinionated about how you write your kernels.

Anyway, for now, closing the issue.

[ZhenshengLee]

May be you are right, and I am facing thrust issues of merge sort function.

See this issue if interested neka-nat/cupoch#62

Thanks.