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

https://www.youtube.com/watch?v=lunJmMBkqLo

by pjmlp • 7 years ago

114 60 7 years ago

pron7• 7 years ago

Here is the same speaker comparing C2 and clang: https://youtu.be/0yrBuPiGk8I

_lbaq• 7 years ago

Just in time compilation, I think it should be called “continuous profile guided compilation” instead, describes better the awesomeness that happens...

chrisseaton7• 7 years ago

Some people differentiate between just-in-time compilation, which is what for example .NET does (or did, last time I checked), where it just literally compiles it as it would ahead-of-time, but at the last second before executing it for the first time, and dynamic compilation, which is for example what Graal does - compiling based on runtime conditions, possibly multiple times with different results as the program executes.

lewurm2• 7 years ago

[...] which is what for example .NET does.

.NET is the platform. There are different implementations for it doing different things.

JIT compilation is still different to AOT even without profile guided optimizations. Simple example: In AOT code you can't embed pointers easily and is often solved with indirection (e.g. something like GOT in ELF).

pron7• 7 years ago

JITs do more than just profile-guided optimizations. Their secret weapon is speculative optimizations that mean they don't need to work hard (and often fail) to prove the soundness of certain optimizations. They're allowed to guess and be wrong.

the8472• 7 years ago

Another advantage they have is that they can focus the spent optimization cycles on hot code.

AOT compilers can't afford running optimization passes in a loop (inline, optimize, inline, optimize, ...) until they reach a fixed point because that would blow up compile times if that were applied to the whole program.

amelius2• 7 years ago

If they do speculative optimizations, then doesn't that open the door to Spectre-like vulnerabilities, but now at the compiler level?

pvg7• 7 years ago

Wait, ignore soundness? How does that work/provide advantage?

exabrial• 7 years ago

I'm curious if GraalVM can do the same rockstar party tricks on Java 11? He uses Java 12, but doesn't go into huge detail why he chose that rather than the LTS.

pron7• 7 years ago

12 is the current JDK version. OpenJDK has no notion of LTS (e.g. you will see no mention of 11 being an LTS on the project page: https://openjdk.java.net/projects/jdk/11/ nor any special designation compared to JDK 12's page), and all versions are equal.

Java's LTS means something that could perhaps be quite different from LTS in other projects. LTS is a service offered by companies to arbitrary JDK versions of their choice (e.g. Azul offers extended support for versions other than those Oracle does); there is nothing special about the development, testing, effort or focus put into those versions. In addition, people can choose to maintain OpenJDK update projects, as Red Hat does for 11. Anyway, JDK 12 is simply the current JDK version, and there is no reason to use an old version for a technical discussion -- there is nothing more stable about it, or any other technical difference -- even if companies offer extended support for it. (I work on OpenJDK at Oracle)

twic• 7 years ago

OpenJDK has no notion of LTS

But two of the main maintainers, Oracle and Red Hat, absolutely do.

LTS is a service offered by companies to arbitrary JDK versions of their choice

And that arbitrary version is 11.

It's technically accurate but substantially disingenuous to suggest that 11 is not Java's current LTS.

repolfx• 7 years ago

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?

kasperni• 7 years ago

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.

astrange2• 7 years ago

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.

grashalm• 7 years ago

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.

imtringued• 7 years ago

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.

pjmlp6• 7 years ago

OpenJDK for Java 12 also does it, as Intel has contributed AVX optimizations to it.

wiradikusuma• 7 years ago

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

luu• 7 years ago

It seems pretty good. Twitter has some talks on this where they claim signifiant performance improvements: https://www.youtube.com/watch?v=PtgKmzgIh4c.

I've heard that the Twitter JVM team has a road show where they've talked to some other large Scala users about the performance improvements. Initially, people are highly skeptical of the claims, but after trying Graal on their internal workloads, they generally see similar results.

Here's a paper which has some explanations for why you might expect Graal to improve Scala performance: http://aleksandar-prokopec.com/resources/docs/graal-collecti...

Recurecur• 7 years ago

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.

Bootvis• 7 years ago

I got quite good results running some Sudoku solving code in GraalVM (FastR). It was faster than an R/Rcpp hybrid:

http://bootvis.nl/fastr-sudokus/

Later I ran into some errors which are supposed to be fixed in the development branch but I haven't tested.

yogthos• 7 years ago

As a side note, GraalVM is quite usable for real world stuff nowadays. Here's an example of running a Clojure web service with Graal that provides JSON endpoints, talks to the database, and does session management: https://github.com/yogthos/graal-web-app-example

The same app can be run on the JVM or compiled statically using Graal. The JVM version takes around a 100 megs of RAM, and has a significant startup time. The Graal version weighs in at 7 megs, and starts up instantly.

mey• 7 years ago

Is it clear what the licensing is/will be for Graal?

Edit: GraalVM CE describes it on the download page https://www.graalvm.org/downloads/

chii• 7 years ago

they don't really clearly list the differece between the CE and the EE version

what is "Improved performance and smaller footprint"? If i use the CE, does it produce worse code somehow?

eby2• 7 years ago

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 legacy) code in Java and R, but most of the newly-minted grads coming in lean towards Python.

As one of the guys pulling all this stuff together, the Graal "polyglot" multilingual VM concept is of tremendous interest as you can imagine. It would be great to be able to package the legacy stuff interoperably with the new stuff no matter the language, even setting aside the bonus of better performance. But it has basically no practical use to us without Python (+ packages!) due to the direction and language inclinations of the group.

Is there anything new happening on that front? Or anything we could do to help it along? Is there more a detailed status page anywhere? Any sense of when this might land in a truly usable form, or what's the hold up?

I'm a bit surprised that the progress with R (with packages) is so far along but the progress with Python (with packages) seems stagnant (at least according to that README). No offense meant to the team, but that's the appearance. Is it the GIL?

[1] https://github.com/graalvm/graalpython, which calls it "early-stage experimental" and "very likely that any Python program that requires any packages at all will hit something unsupported".

sjcoles• 7 years ago

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 though (8650u and 32gb of ram). Most of this time was spent on pymysql and jinja2's compilation.

[1] https://nuitka.net/

eby2• 7 years ago

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.

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

Related Stories