[mister_hn]

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

[chrisseaton]

This 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]

O(1) as implementation time maybe, but as performance time is O(n)

[chrisseaton]

I 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).

[diggan]

Guess 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.

[jjoonathan]

Can 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 :)

[pjmlp]

Because it is more productive and safer, instead of forcing everyone to learn C and C++.

A lesson that Khronos learnt too late regarding OpenCL.

[mister_hn]

Safer is relative: also Rust, Go and Java can be very unsafe

[pjmlp]

Memory corruption bugs + UB + logical errors >= logical errors