Live data from Hacker News

A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

youtube.com

61–64 of 64 posts

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#61

A bit OOT, has anyone tried Scala on Graal? How's it?

If Graal and Scala interest you, then you should be aware of the Scala Native project:

http://www.scala-native.org/en/v0.3.9-docs/ https://github.com/scala-native/scala-native

It provides manual memory management as needed, making it suitable for even hard real time applications.

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#62
post #8

From what I know, GraalVM EE (Enterprise Edition) does do loop vectorisation. This will lead to an interesting problem if they want to replace C2 with Graal. Are they willing to regress performance for some open-source-only users, even if it's a performance win for others?

Contrary to popular believe, automatic loop vectorization is not as important to most Java workloads as one might think. It gets a lot of visibility as it causes significant peak performance differences in micro-benchmarks. In the end, you should not trust standard benchmarks and definitely not micro-benchmarks. Do perform tests with your own workload.

But this is only true because the Hotspot JVM just isn't meant to be used for high performance code. In theory with a good enough JIT, it should be possible to achieve high performance even in Java. One day Java might have value types and then these optimizations will be able to shine.

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#63
post #60
post #56

What's the current status of Graal's Python implementation in terms of reaching actual usability? The README on its GitHub repo [1] doesn't inspire much confidence but whenever I check that wording hasn't changed. I've been following Graal for quite some time, both as a former PLDI guy but also for my day job. I work in bioinformatics software (mostly cancer genomics research) and our group has a ton of (mostly legac…

I had decent luck with Nuitka[1] as long as the project is 100% python. The executables are large but have been mostly portable IME (some glib problems can arise though). Largest project I compiled was only ~1000 lines but used external deps of pymysql, jinja2, ldap3 along with the stdlib's shutil, tempfile, pathlib, and the base os lib without issues. It takes ~30 minutes to compile on a decently powerful machine th…

Thanks, but I don't see what that has to do with Graal or multi-language interoperability which is the key thing here. We have substantial code in Java, R and Python that could all benefit from being able to call one another from within the same process.

An alternative Python compiler by itself frankly buys us very little. Perhaps Jython, if it weren't targeting 2.7.x.

Re: A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video]

#64
post #9

Earlier quoted context omitted.

Yes, this will be very interesting. Also, since GraalVM is pretty modular. Will someone provide a free/open source version with loop vectorisation and other goodies.

That shouldn't be interesting in Java. Most programs can't be autovectorized, especially in a language without any SIMD constructs. If you try to guess what the compiler thinks vectorization looks like, you'll probably get it wrong.

Java will be exposing parallelization constructs by means of project Panama: http://cr.openjdk.java.net/~vlivanov/panama/vectors/vectors....
Post reply on HN