{"action":"created","issue":{"url":"https://api.github.com/repos/jcuda/jcuda-main/issues/11","repository_url":"https://api.github.com/repos/jcuda/jcuda-main","labels_url":"https://api.github.com/repos/jcuda/jcuda-main/issues/11/labels{/name}","comments_url":"https://api.github.com/repos/jcuda/jcuda-main/issues/11/comments","events_url":"https://api.github.com/repos/jcuda/jcuda-main/issues/11/events","html_url":"https://github.com/jcuda/jcuda-main/issues/11","id":194496392,"number":11,"title":"Building wrappers to CUB calls","user":{"login":"nakul02","id":5394361,"avatar_url":"https://avatars.githubusercontent.com/u/5394361?v=3","gravatar_id":"","url":"https://api.github.com/users/nakul02","html_url":"https://github.com/nakul02","followers_url":"https://api.github.com/users/nakul02/followers","following_url":"https://api.github.com/users/nakul02/following{/other_user}","gists_url":"https://api.github.com/users/nakul02/gists{/gist_id}","starred_url":"https://api.github.com/users/nakul02/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nakul02/subscriptions","organizations_url":"https://api.github.com/users/nakul02/orgs","repos_url":"https://api.github.com/users/nakul02/repos","events_url":"https://api.github.com/users/nakul02/events{/privacy}","received_events_url":"https://api.github.com/users/nakul02/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-12-09T02:11:34Z","updated_at":"2016-12-10T10:34:10Z","closed_at":null,"body":"Would it make sense for JCuda and the Mavenized-JCuda project to include Java bindings to NV Labs' CUB (http://nvlabs.github.io/cub/index.html) ?\r\nThe bindings would only be to Device-wide primitives. These include Scan, Reduce, Select, Sort, SpMv, SegmentedSort, SegmentedReduce.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/jcuda/jcuda-main/issues/comments/266198752","html_url":"https://github.com/jcuda/jcuda-main/issues/11#issuecomment-266198752","issue_url":"https://api.github.com/repos/jcuda/jcuda-main/issues/11","id":266198752,"user":{"login":"jcuda","id":13698062,"avatar_url":"https://avatars.githubusercontent.com/u/13698062?v=3","gravatar_id":"","url":"https://api.github.com/users/jcuda","html_url":"https://github.com/jcuda","followers_url":"https://api.github.com/users/jcuda/followers","following_url":"https://api.github.com/users/jcuda/following{/other_user}","gists_url":"https://api.github.com/users/jcuda/gists{/gist_id}","starred_url":"https://api.github.com/users/jcuda/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jcuda/subscriptions","organizations_url":"https://api.github.com/users/jcuda/orgs","repos_url":"https://api.github.com/users/jcuda/repos","events_url":"https://api.github.com/users/jcuda/events{/privacy}","received_events_url":"https://api.github.com/users/jcuda/received_events","type":"User","site_admin":false},"created_at":"2016-12-10T10:34:10Z","updated_at":"2016-12-10T10:34:10Z","body":"Regarding JCudpp: I haven't yet updated it for CUDA 8. Although this would only mean to re-compile it for CUDA 8, the user base of JCudpp seems to be very small, and admittedly, this had lower priority than other tasks. But considering the recent update of CUDPP to 2.3, the priority has now increased, and I'll try to do the update soon, although I can't make any promises right now regarding the exact timeline.\r\n\r\n---\r\n\r\n\r\nRegarding CUB, I still have to study it further. Broadly speaking (and without having looked at the code), there are different possible \"levels\" of integration:\r\n- None. Just mentioned for completeness: I'll have to try out how well it works to just include CUB headers into own kernels, and then compile and load them as PTX\r\n- Precompiled PTX: Similar to jcuda-vec, I could imagine several precompiled PTX files for the functions. This may be a slippery slope, because there are many degrees of freedom. First, regarding the *configuration* template parameters (`BLOCK_SIZE` etc), second regarding the *type* template parameters (whether a reduction operates on `float` or `int`), and third, regarding the *operation* parameters. A quick glance at the headers shows dedicated methods like `DeviceReduce::Sum`, but they seem to delegate to a generic reduction that receives a `ReductionOpT` parameter for \"any\" binary operator. I'll have to review the code more thoroughly to see how exactly these degrees of freedom could be exposed. (Another caveat of PTX is that it is, to some extent, specific for the target architecture, e.g. regarding the compute capability...)\r\n- Runtime compilation: This *may* be a viable and in fact very flexible option. *Very* roughly speaking: There could be a set of `String` (!) templates for various operations, that additionally allow the configuration parameters mentioned above to be inserted as strings as well, and then compile the result with the NVRTC\r\n- \"An API\": This would be the approach that you likely referred to when mentioning JCudpp. There could be a class, offering classical, simple Java functions, for different types (`float`, `int`...), probably with many parameters for the remaining parts of the configuration.\r\n\r\nIt would also be desirable to have multiple levels of abstraction here. For example, it would be nice to have a convenient \"API\" layer, but still have the *option* to go one level deeper and, for example, manually specify some of the parameters that are *not* exposed in the API level. \r\n\r\nBut again, this classification is very rough and rather a \"brainstorming\". I'll have to allocate some time to familiarize myself with CUB.\r\n\r\n"}}
{"actor":{"display_login":"jcuda"}}