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

Post by chrisseaton » Mon, Jun 17, 2019, 7:40 AM UTC

pjmlp wrote: post #50

chrisseaton wrote: post #41

Earlier quoted context omitted.

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

Post by kjeetgill » Mon, Jun 17, 2019, 8:37 AM UTC

pjmlp wrote: post #49

kjeetgill wrote: post #44

Earlier quoted context omitted.

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.

Post by pjmlp » Mon, Jun 17, 2019, 1:04 PM UTC

lewurm wrote: post #52

chrisseaton wrote: post #42

Earlier quoted context omitted.

> There are different implementations for it doing different things. And are they now speculative? They weren't for the first 15 years or so.

CoreCLR started to implemented Tiered Compilation https://github.com/dotnet/coreclr/blob/master/Documentation/... It's experimental currently, no profile guided optimizations _yet_

Post by [deleted] » Mon, Jun 17, 2019, 3:18 PM UTC

pjmlp wrote: post #54

chrisseaton wrote: post #51

Earlier quoted context omitted.

So which of these implementations does speculation? I remember when RyuJIT came out it still wasn't speculative - has that now changed? If you read the blog posts, they always talk about speculation being something they may try in the future. I've not seen anything where they say they went ahead and implemented it.

Here is some information Background JIT overview, which is a kind of PGO for the .NET Frameworok https://msdn.microsoft.com/en-us/magazine/mt683795.aspx And I think this goes into line with what you are discussing, https://github.com/dotnet/coreclr/pull/21270 I also agree that many things remain to be done in line with what Graal is capable of.

Post by pron » Mon, Jun 17, 2019, 3:59 PM UTC

astrange wrote: post #47

the8472 wrote: post #10

Earlier quoted context omitted.

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.