Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GrCUDA: A Polyglot Language Binding for CUDA in GraalVM

devblogs.nvidia.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: GrCUDA: A Polyglot Language Binding for CUDA in GraalVM

#21

Post by The_rationalist »

Veedrac wrote: post #15
The_rationalist wrote: post #9

What if web browsers included graalvm as an alternative to WebAssembly?

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.

Re: GrCUDA: A Polyglot Language Binding for CUDA in GraalVM

#22

Post by suyash »

jjoonathan wrote: post #16
suyash wrote: post #11

This is wonderful news for Java Developers, however my main concern is with CUDA being a proprietary technology, only works on NVIDIA GPU's.

Worse, 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.

yeah or even on your local MacBook Pro for development can't use it.

Re: GrCUDA: A Polyglot Language Binding for CUDA in GraalVM

#23

Post by Veedrac »

The_rationalist wrote: post #21
Veedrac wrote: post #15

Earlier quoted context omitted.

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.

Re: GrCUDA: A Polyglot Language Binding for CUDA in GraalVM

#24

Post by needusername »

smabie wrote: post #14

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 ag…

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

Re: GrCUDA: A Polyglot Language Binding for CUDA in GraalVM

#25

Post by mister_hn »

chrisseaton wrote: post #6
mister_hn wrote: post #2

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

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.

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

Re: GrCUDA: A Polyglot Language Binding for CUDA in GraalVM

#26

Post by mister_hn »

pjmlp wrote: post #5
mister_hn wrote: post #2

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

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.

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

Re: GrCUDA: A Polyglot Language Binding for CUDA in GraalVM

#27

Post by chrisseaton »

mister_hn wrote: post #25
chrisseaton wrote: post #6

Earlier quoted context omitted.

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.

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

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

Re: GrCUDA: A Polyglot Language Binding for CUDA in GraalVM

#28

Post by repolfx »

Veedrac wrote: post #15
The_rationalist wrote: post #9

What if web browsers included graalvm as an alternative to WebAssembly?

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.

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.

Re: GrCUDA: A Polyglot Language Binding for CUDA in GraalVM

#29

Post by Veedrac »

repolfx wrote: post #28
Veedrac wrote: post #15

Earlier quoted context omitted.

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.

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…

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.

Re: GrCUDA: A Polyglot Language Binding for CUDA in GraalVM

#30

Post by pjmlp »

mister_hn wrote: post #26
pjmlp wrote: post #5

Earlier quoted context omitted.

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.

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

Memory corruption bugs + UB + logical errors >= logical errors
Post reply on HN