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

41–50 of 64 posts

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

#41

Post by chrisseaton »

pjmlp wrote: post #39
chrisseaton wrote: post #21

Earlier quoted context omitted.

> to me this case is still a JIT jittin' I think the point is that some JITs never do this kind of optimisation - they just produce the same code an AOT compiler would, but at runtime. Such as the .NET JIT.

I guess you need to update your knowledge regarding the several .NET JITs in use.

As I cautioned in another comment

> (or did, last time I checked)

Do implementations of .NET JITs now do speculative optimisations or dynamic compilation? They didn't see the need for it for about 15 years.

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

#42

Post by chrisseaton »

lewurm wrote: post #34
chrisseaton wrote: post #4

Earlier quoted context omitted.

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…

> [...] 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).

> There are different implementations for it doing different things.

And are they now speculative? They weren't for the first 15 years or so.

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

#43

Post by chii »

mey wrote: post #37

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/

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?

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

#44

Post by kjeetgill »

pjmlp wrote: post #39
chrisseaton wrote: post #21

Earlier quoted context omitted.

> to me this case is still a JIT jittin' I think the point is that some JITs never do this kind of optimisation - they just produce the same code an AOT compiler would, but at runtime. Such as the .NET JIT.

I guess you need to update your knowledge regarding the several .NET JITs in use.

Maybe I'm only familiar with "the main one" and mono... Are there other .NET VMs?

If I recall correctly, it will do constant folding, but won't speculate that a certain parameter is always essentially constant at runtime, but wasn't at compile time.

An easy example is a config loaded from a file as the server boots but never changes for the lifetime of the process. That won't constant fold without speculation.

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

#46

Post by kjeetgill »

pron wrote: post #33
twic wrote: post #28

Earlier quoted context omitted.

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

> 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'…

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.

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

#47

Post by astrange »

the8472 wrote: post #10
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.

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.

This almost never matters. You just start at the leaves and go up and then you're done. Most people aren't interested in complicated superoptimizations, because a predictable compiler is more important.

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

#48

Post by astrange »

kasperni wrote: post #9
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?

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.

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

#49

Post by pjmlp »

kjeetgill wrote: post #44
pjmlp wrote: post #39

Earlier quoted context omitted.

I guess you need to update your knowledge regarding the several .NET JITs in use.

Maybe I'm only familiar with "the main one" and mono... Are there other .NET VMs? If I recall correctly, it will do constant folding, but won't speculate that a certain parameter is always essentially constant at runtime, but wasn't at compile time. An easy example is a config loaded from a file as the server boots but never changes for the lifetime of the process. That won't constant fold without speculation.

There is the old style JIT, RyuJIT introduced with .NET Framework 4.6, MDIL, .NET Native, Mono, .NET CF, IL2CPP, and the research ones from Singularity and Midori.

So while it is hard to state what each AOT/JIT compiler is capable of, naturally they aren't 100% all the same.

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

#50

Post by pjmlp »

chrisseaton wrote: post #41
pjmlp wrote: post #39

Earlier quoted context omitted.

I guess you need to update your knowledge regarding the several .NET JITs in use.

As I cautioned in another comment > (or did, last time I checked) Do implementations of .NET JITs now do speculative optimisations or dynamic compilation? They didn't see the need for it for about 15 years.

15 years ago there weren't RyuJIT which replaced the JIT you learned from, MDIL (Windows 8/8.1), .NET Native (UWP), IL2CPP (Unity), and the research ones from Singularity and Midori.

In what concerns the need for it, they have been trying to make C# more relevant for the kinds of C++ workloads and getting among the first places at TechEmpower.

So .NET has been getting Modula-3 like low level handling of value types within a GC environment, RyuJIT is now tiered, supports SIMD and some automatic vectorization.

.NET Framework 4.6 got the first version of what is the .NET way of doing AppCDS.

There are a couple of blog posts regarding RyuJIT improvements with each release after its introduction.

Post reply on HN