Live data from Hacker News

GrCUDA: A Polyglot Language Binding for CUDA in GraalVM

devblogs.nvidia.com

11–20 of 30 posts

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

#13
post #10

Earlier quoted context omitted.

It isn't fashionable.

What do you mean?

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.

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

#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 aggressive optimizations ideal for abstraction heavy code/languages (like scala). Would be nice to use because scala generates garbage like it’s no tomorrow.

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

#15

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.

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

#16
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.

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

#17
post #13

Earlier quoted context omitted.

What do you mean?

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.

WebAssembly got formal semantics with formal proof of soundness. PNaCl (and LLVM) still doesn't.

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

#18
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…

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.

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

#19
post #17
post #13

Earlier quoted context omitted.

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.

WebAssembly got formal semantics with formal proof of soundness. PNaCl (and LLVM) still doesn't.

Politics, and yet it doesn't have bounds checking support.

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

#20
post #19
post #17

Earlier quoted context omitted.

WebAssembly got formal semantics with formal proof of soundness. PNaCl (and LLVM) still doesn't.

Politics, and yet it doesn't have bounds checking support.

BTW chrome webassembly is 2 time slower than pnacl.
Post reply on HN