3 ms·
Why should one use this vs. using C/C++ bindings for CUDA and load them in other languages (if required)? I believe it underperforms in comparison with raw C o
by mister_hn 7y ago
Why should one use this vs. using C/C++ bindings for CUDA and load them in other languages (if required)?
I believe it underperforms in comparison with raw C or C++ implementation, just because of the overhead that goes through GraalVM
- jjoonathan 7y agoCan GrCUDA give you a good testing / CI story? IIRC if you want to test you code on a GPU-less server, the other option is GPUOcelot, which is (also) 3rd party and no longer maintained. EDIT: or you can install CUDA from 2009 before they stripped out the software emulator and use no features from the last decade, but then you might as well just use OpenCL :)
- diggan 7y agoGuess it would be easier to build a library using Cuda in Java + JS + Ruby + Python + Rust at the same time, as that's kind of what GraalVM would help a lot with. Basically, anything polyglot + Cuda would be easier with this.
- pjmlp 7y agoBecause it is more productive and safer, instead of forcing everyone to learn C and C++. A lesson that Khronos learnt too late regarding OpenCL.
- chrisseaton 7y agoThis is an O(1) solution (one integration works for all languages). You're proposing an O(n) solution (binding into individual languages.) That's why.
- mister_hn 7y agoO(1) as implementation time maybe, but as performance time is O(n)
- chrisseaton 7y agoI don't think GraalVM polyglot interop is O(n). It uses multi-dimensional polymorphic inline caching (dispatch chains) which specialises for the number of languages using it, and so the interface between two languages is O(1).