4 ms·
GrCUDA: A Polyglot Language Binding for CUDA in GraalVM
- mister_hn 7y agoWhy 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).
- hellofunk 7y agoSee also: the Futhark programming language.
- xiphias2 7y agoIt's great to have GraalVM CUDA support, but LLVM PTX output of many languages is full of bugs and missing features. I wish NVIDIA would give more support to those integrations that already exist, but experimental for many years now (i.e. Julia, Rust).
- The_rationalist 7y agoWhat if web browsers included graalvm as an alternative to WebAssembly?
- pjmlp 7y agoIt isn't fashionable.
- The_rationalist 7y agoWhat do you mean?
- pjmlp 7y agoWebAssembly is the consequence of Mozilla not adopting PNaCL, and its advocates usually hand wave all the multi-language bytecode formats used throughout the industry since UNCOL, as if it is the very first of its kind.
- sanxiyn 7y agoWebAssembly got formal semantics with formal proof of soundness. PNaCl (and LLVM) still doesn't.
- pjmlp 7y agoPolitics, and yet it doesn't have bounds checking support.
- The_rationalist 7y agoBTW chrome webassembly is 2 time slower than pnacl.
- Veedrac 7y agoYou'd lose a lot and I'm not sure what you gain. Sans a few niggles here and there, WASM is pretty great for the web. It's small, lightweight, sandboxed, verifiable, fast to JIT, has fallbacks to ASM.js/stock JS, mostly easy to compile to, simple to build tooling for, etc.
- suyash 7y agoThis is wonderful news for Java Developers, however my main concern is with CUDA being a proprietary technology, only works on NVIDIA GPU's.
- jjoonathan 7y agoWorse, you can't test it without an NVIDIA GPU on your CI server. NVIDIA used to support software emulation but removed it in 2009. GPUOcelot picked up the torch but is unmaintained since 2015.
- suyash 7y agoyeah or even on your local MacBook Pro for development can't use it.
- smabie 7y agoGraalVM is super exciting. Suddenly the major reason against adopting the JVM for certain use cases has gone away: start-up time. That said, I’ve spent a couple hours trying to get GraalVM to produce a native image of a moderately complex Scala project (20 kloc) I work on in my spare time, and can’t get it to work. Would be nice because supposedly not only does GraalVM reduce start-up time but features some highly aggressive optimizations ideal for abstraction heavy code/languages (like scala). Would be nice to use because scala generates garbage like it’s no tomorrow.
- vips7L 7y agoI'm really hoping for native to become the standard for java. I'm really looking forward to this months release as graal will finally support java > 8.
- needusername 7y ago> but features some highly aggressive optimizations ideal for abstraction heavy code/languages (like scala). Then native image may not be for you yet. Topline performance of native image is currently a lot worse than that of Graal compiler. > Would be nice to use because scala generates garbage like it’s no tomorrow. Then native image definitely isn't for you yet. The GC of native image is currently a lot worse than what you get with GraalVM / HotSpot. One of the annoying things about Graal are there are a lot of different things all under the Graal umbrella. Also there are a lot of limitations of native image that people often don't talk about. These limitations basically make it not Java anymore. One person once summarized native image as, "even less Java than Android".