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

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

youtube.com

Post reply on HN
Print view View original

11–20 of 64 posts

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

#11

Post by pron »

exabrial wrote: post #6

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.

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)

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

#12

Post by amelius »

pron wrote: post #5
_lbaq wrote: post #3

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

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.

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

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

#13

Post by grashalm »

repolfx wrote: 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.

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

#15

Post by luu »

wiradikusuma wrote: post #14

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

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

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

#16

Post by pvg »

pron wrote: post #5
_lbaq wrote: post #3

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

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.

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

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

#17

Post by 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/

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

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

#18

Post by zlynx »

pvg wrote: post #16
pron wrote: post #5

Earlier quoted context omitted.

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.

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

A function could be compiled assuming the passed argument is always 2. All of the code for other values is just left out.

As long as the compiled code has a check for values that are not 2 this code works great. It isn't correct though.

At least, that's my interpretation.

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

#19

Post by pvg »

zlynx wrote: post #18
pvg wrote: post #16

Earlier quoted context omitted.

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

A function could be compiled assuming the passed argument is always 2. All of the code for other values is just left out. As long as the compiled code has a check for values that are not 2 this code works great. It isn't correct though. At least, that's my interpretation.

Maybe I'm getting tripped up in the terminology here but to me this case is still a JIT jittin' - you look at runtime data and decide it's worth it to crank out a special case optimization for the input of 2. You produce that that optimization, which is sound along with a check to make sure it is applied only in the special case. You get to defer other optimization. The advantage here still seems to come from the runtimeness of things rather than from being clever about soundness and there's really no guessing about soundness. So perhaps that's not it.

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

#20

Post by chrisseaton »

amelius wrote: post #12
pron wrote: post #5

Earlier quoted context omitted.

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.

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

This isn't speculation as in speculative execution, it's speculation as in speculating that a condition is true that cannot be proved to be true, so it's not the same thing.

An example of this kind of speculation is speculating that there will only ever be one thread in a system, and removing locks. If that speculation ever proves to be wrong - a second thread is created - the locks are put back into the system.

That doesn't related to spectre, as when the speculation is reversed the whole programs is first brought to a safe halt - it isn't fine-grained enough to be useful for Spectre.

Unrelated, it is true that compilers need to be aware of Spectre-like vulnerabilities, and Graal does include experimental support for that.

Post reply on HN