
A Race of Two Compilers: GraalVM JIT versus HotSpot JIT C2 [video] - pjmlp
https://www.youtube.com/watch?v=lunJmMBkqLo
======
yogthos
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](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.

------
Bootvis
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/](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.

------
repolfx
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?

~~~
grashalm
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
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.

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

~~~
pron
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.

~~~
pvg
Wait, ignore _soundness_? How does that work/provide advantage?

~~~
ddragon
For example a JIT compiler can, based on the runtime information + inference,
discard multiple branches of a function that are effectively pointless and
possibly even just inline the results if given those inputs the function is
deterministic.

Of course, the function it compiled will actually not work with any different
but still valid arguments, but that's not really trouble since the JIT
compiler will simply evaluate that the already compiled version won't work for
those as the function is called and compile a new version of the function for
the new types just before. A pure ahead-of-time compiler wouldn't be able to
optimize so aggressively since it would lead to an exponential explosion of
possible inputs combinations most of which will very likely never happen.

~~~
pvg
I put it in a bit more detail in a sibling comment but to me, there's no
'guessing about soundness and being wrong' in that particular scenario.

~~~
ddragon
I guess it depends on the perspective and interpretation of soundness. If a
JIT-compiler AoT compiles your entire program but infers that your function
that implements logic that works for every number (as you defined it using the
Number interface within the rules of it's type system) will only use 32 bits
integers, then it will compile code that effectively does not hold up to the
property that was established. The fact that it will stop execution the moment
it reaches an invalid path and correct it doesn't change that.

~~~
pvg
It could be and that would be uninteresting. But it's not hard to come up with
a (contrived, limit-casey) optimization approach that does actually make
guesses about soundness.

Let's say you wanted to optimize a short instruction sequence with a small
domain of inputs. You could try to generate all (or at least, zillions) of
similarly-sized possible instruction sequences and check them for soundness
and performance. Now you're really making soundness guesses. Do real JITs
actually make that sort of soundness guess (not that kind of attempt at
optimization, obviously)?

~~~
pron
All the time, and BTW, I didn't say JITs sacrifice soundness but that they
don't require _proof_ of soundness. That's different as I'll show.

Let me give you two common examples: virtual calls and branches. A JIT will
speculatively devirtualize and inline a virtual call at a particular callsite
if it has only encountered one or a small number of concrete instances, even
if it can't prove that those are the only instances that can be encountered at
that callsite. This is still sound because the JIT will emit a trap that will
trigger if an unknown target is ever encountered, in which case it will
deoptimize the compilation, go back to the interpreter and then compile again
under new assumptions. Another example is branch elimination. If a JIT only
ever encounters the program taking one side of a branch, it will only compile
that branch (and introduce a trap), even if it can't prove that only that side
will _ever_ be taken.

~~~
pvg
Thanks! I did (eventually) figure it out, I initially misread it as something
like:

1\. Jettison soundness

2\. ???

3\. Performance profit.

Which seems like witchcraft, then again JITs are full of witchcraft. But it's
also not what you wrote. I've now come to understand the two chief weapons of
the JIT remain surprise, fear, ruthless efficiency and an almost fanatical
devotion to the Pope.

------
pron
Here is the same speaker comparing C2 and clang:
[https://youtu.be/0yrBuPiGk8I](https://youtu.be/0yrBuPiGk8I)

------
eby
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](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
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/](https://nuitka.net/)

~~~
eby
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.

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

~~~
luu
It seems pretty good. Twitter has some talks on this where they claim
signifiant performance improvements:
[https://www.youtube.com/watch?v=PtgKmzgIh4c](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...](http://aleksandar-
prokopec.com/resources/docs/graal-collections.pdf)

------
mey
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/](https://www.graalvm.org/downloads/)

~~~
chii
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?

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

~~~
pron
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/](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
> 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.

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

BTW, Oracle contributes ~90% and Red Hat ~5%.

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

Either way that has little significance here. It is not the most popular
version of Java in use today (that would be 8u2XX) nor is it any more
production-ready or stable than 12. You can say that we're interested in
results for the current version of Java or in the most popular one. I don't
understand why it would be particularly interesting to discuss JDK 11, which
is neither.

~~~
kjeetgill
I'm really not sure where your confusion is coming from.

The post itself is interesting on two fronts: as a new emerging technology but
also as a leverageable tool. As an OpenJDK developer I understand your
interests are more about the former.

For many of us are using Oracle or RedHat LTS builds, we are running either 8
or 11 for "reasons". It's pretty natural to know if these new changes to the
platform apply to a given version without asking.

