[FEA] Separate device and host API

[cjnolet]

After suggestions from a few folks, I think it's time to think about separating the namespaces / APIs for device and host code. As @wphicks points out, this should also help us speed up compile times overall and as @MatthiasKohl has suggested in reference to the random number generation APIs, it would make for a cleaner and more explicit API. This will also allow us to isolate the host code in .hpp files and only use .cuh files for code actually containing device functions.

Currently, we're working to refactor mostly host code, as we're exposing our public API as .hpp files. We should have device-specific functions in .cuh files and be careful about the extensions we use.

[github-actions]

This issue has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d if there is no activity in the next 60 days.

[cjnolet]

@MatthiasKohl after recent discussions, I realized we were talking about slightly different things wrt to host vs device APIs. I was taking "device API" to mean that some device functions should be exposed directly through the public API, and should probably be placed in a separate directory or namespace to make them easier to find and use, vs functions which can be invoked from the host and will launch the necessary kernels on the device.

That said, I'm just leaving a note here to remove the ambiguity and state that this issue is in fact related to separating public device functions from public host functions. I will create another issue to handle CUDA vs non-CUDA enabled compilers.

[cjnolet]

These relevant files have been renamed (new files created and old files deprecated for 22.04) and I’ve created #555 to remove the files in a future release. Closing this as complete.

[MatthiasKohl]

@cjnolet Should we open another issue for getting a host-only API specifically for RNG?

What has happened now is that we basically just renamed the rng.hpp file to rng.cuh, but I don't agree that host and device APIs have been separated: a quick look into the new rng.cuh clearly shows host objects/methods such as RngState or Rng right next to device-only objects/functions such as PCGenerator or custom_next.
Again, it's important to understand that separating CUDA vs non-CUDA compilers is just a side-effect of clearly separating host-only from mixed and device-only APIs (and ensuring that mixed APIs are as small as possible).
For RNG, this is fairly easy to do, since the scope of what the host-code does is so different from what the device-code does.

[cjnolet]

@MatthiasKohl completely agree with you that RNG has not separated the host from device APIs yet (and all that has been done on it thus far is moving tthe current code over to a cuh extension).

I closed this issue because in the end it just came to mean using the hpp and cuh file extensions to more appropriately mark host and device compilable code. I added the outcome of our RNG API redesign discussion to #406 and figured we would track the api updates for separating the host and device APIs there since both are likely to happen in the same PR. What do you think?

[MatthiasKohl]

@cjnolet Makes sense, I oversaw that #406 was still open, so it makes sense to track those other changes there.