Re:Guide to the CoreCLR Source Code
by chrisseaton on Friday March 24, 2017 @01:05PM
(#13950404)
I tried to find any studies because the claim surprised me, but I didn't find any, so I wasn't going to try to refute that without any data.
But I can say that the number of research papers around the JIT in the JVM is probably and order of magnitude more than around the CLR. Someone else linked to 'Research papers in the .NET source', and guess what? Several of them are really JVM papers, talking about how they've used the same technique.
The CLR has some APIs to help with that, but they aren't at the same level as what JVM JIT compilers are capable of.
Additionally there is PGO support between runs and explicit SIMD support.
IBM J9 also does support caching JIT code thought.
Re:Guide to the CoreCLR Source Code
by JoachimSchipper on Friday March 24, 2017 @03:42PM
(#13951652)
Yes, that's an odd claim. You can construct a synthetic benchmark where C#'s support for value types lets .Net beat a pointer-chasing JVM, and I'm sure there are other corners where .Net wins; but that's not the general rule.
That’s... not really true. JRE’s HotSpot is much faster than CLR, even today.
I’d be interested to see benchmarks proving your argument, because basically every benchmark out there proves you wrong.
Sun’s HotSpot does recompilation and profiling, to reoptimize depending on use case, while CLR only JIT’s once, so the base performance is very low. This is also why HotSpot can reach better-than-C performance in some cases (because it can optimize at runtime for actually taken code paths, and jump to interpreted code for rarely taken paths), while .NET (and native code) can not. (This is what gives HotSpot the name – it recognizes hot spots, and swaps them out for more and more optimized versions at runtime)