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 :)
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.
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).
It'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).
WebAssembly 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.
You'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.
You'd lose a lot and I'm not sure what you gain
So gaining java, ruby, R, python, etc support for the web are no gain ?
But the added value of graalVM is far beyond that, it revolutionize programming by allowing true polyglotism.
In economic terms, it would mean making accesible to the web millions of libraries which have a human/hours development cost of hundreds of billions of dollars.
Graal is a better target for these runtimes than WASM is, true, but Python-on-Graal is still a terrible target for the web. Huge runtimes with large memory footprints and startup times don't make for a pleasant user experience.
Polygot support, as extremely cool as it is, would be even less of a revolution inside the browser than it has been natively.
The web is anything but small/lightweight and WASM requires a full blown JIT a la V8 to get good performance, so WASM being "small" (relative to what?) seems hardly a benefit.
JVMs are sandboxed and verifiable too, not sure what use a fallback to stock JS is but you can run a JVM in JS (look at TeaVM), it's way easier to emit bytecode for almost any modern language than WASM simply because JVMs do garbage collection for you and it's not really any easier to build tooling for WASM than any other VM.
In the end the main reason to do WASM over other VMs is that this way Mozilla/Chrome guys get to own it, instead of a competing firm.
WASM doesn't need a JIT, it needs a compiler. Unlike a standard JIT, you don't need decompilation and instrumentation. WASM is also designed so that browsers can reuse their JS JIT as a WASM compiler. Even from a JIT perspective, the difference between a lightweight JIT (eg. LuaJIT) and the heavyweight stuff used for JS is huge, and then the gap between JS JITs and Graal is a second such chasm. This equivalence is a false one.
Graal is not designed to be verifiable the way WASM is. We learnt enough from applets to not repeat that mistake.
GC is a distraction; WASM's opt-in is much better than Graal's by-default for use as a general compilation target.
WASM wasn't chosen disingenuously. Nothing else filled the role. If something did they would have used that instead.
GraalVM 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.
I'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.
> 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".
I believe it underperforms in comparison with raw C or C++ implementation, just because of the overhead that goes through GraalVM
reply