4 ms·

I want to note something that my interest some: The second biggest fear which made Sun sue Microsoft was that when MS licensed Java, their VM was faster than

I want to note something that my interest some: The second biggest fear which made Sun sue Microsoft was that when MS licensed Java, their VM was faster than Sun's. Microsoft is (was?) the king of JIT. Technically biggest since if theirs was faster, they wouldn't have cared for Microsoft's anyway. Even now CLR is generally considered much faster than JRE. I don't know how Chakra compares against v8 but then it also depends on what makes money for MS.

chrisseaton 10y ago
> Microsoft is (was?) the king of JIT. Hmmm really? I'm not sure I can think of many technological breakthroughs in the area of JITs that Microsoft have been responsible for? Google and Mozilla have made lots of advances, as have Sun and Oracle, and lots of academics like the PyPy people, HP with Dynamo. What have Microsoft done in the area of JITs that so notable as to earn them the title 'king' of JITs? Can you say anything specific?
- NeverTrump 10y ago
  It's my first meaningful sentence you retard.
  - jeff_petersen 10y ago
    Please don't use ableist slurs :^)
  - dang 10y ago
    We've banned this account for violating the HN guidelines.
- cm2187 10y ago
  Mostly I never understood the point of JIT in the .net framework. You pay a price in term of startup time, but the reality is that you can only run .net on x86 and x64. So we might as well have saved the trouble. And the first time .net was given an opportunity to run on ARM (WinRT), they disallowed regular .net applications in order to introduce a toll through the windows store. We would have been better off without JIT. Even now with ARM. You compile to 3 architectures,... so what?
  - chrisseaton 10y ago
    Normally I would argue that the point is that it allows speculative runtime optimisations, but .NET doesn't do that.
kuschku 10y ago
> Even now CLR is generally considered much faster than JRE. 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)
- chrisseaton 10y ago
  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.
- pjmlp 10y ago
  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.
- JoachimSchipper 10y ago
  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.
abiox 10y ago
> Even now CLR is generally considered much faster than JRE really? since when? can't say i've ever heard this claim before.
- ledgerdev 10y ago
  Got to agree with you. The only thing the CoreCLR might be quicker at is starting up, and maybe a little better memory usage though I don't have any numbers and this is just a feeling from using both. Anyone know for sure on this?

chrisseaton 10y ago

> Microsoft is (was?) the king of JIT. Hmmm really? I'm not sure I can think of many technological breakthroughs in the area of JITs that Microsoft have been responsible for? Google and Mozilla have made lots of advances, as have Sun and Oracle, and lots of academics like the PyPy people, HP with Dynamo. What have Microsoft done in the area of JITs that so notable as to earn them the title 'king' of JITs? Can you say anything specific?

NeverTrump 10y ago
It's my first meaningful sentence you retard.
- jeff_petersen 10y ago
  Please don't use ableist slurs :^)
- dang 10y ago
  We've banned this account for violating the HN guidelines.
cm2187 10y ago
Mostly I never understood the point of JIT in the .net framework. You pay a price in term of startup time, but the reality is that you can only run .net on x86 and x64. So we might as well have saved the trouble. And the first time .net was given an opportunity to run on ARM (WinRT), they disallowed regular .net applications in order to introduce a toll through the windows store. We would have been better off without JIT. Even now with ARM. You compile to 3 architectures,... so what?
- chrisseaton 10y ago
  Normally I would argue that the point is that it allows speculative runtime optimisations, but .NET doesn't do that.

kuschku 10y ago

> Even now CLR is generally considered much faster than JRE. 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)

chrisseaton 10y ago
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.
pjmlp 10y ago
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.
JoachimSchipper 10y ago
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.

abiox 10y ago

> Even now CLR is generally considered much faster than JRE really? since when? can't say i've ever heard this claim before.

ledgerdev 10y ago
Got to agree with you. The only thing the CoreCLR might be quicker at is starting up, and maybe a little better memory usage though I don't have any numbers and this is just a feeling from using both. Anyone know for sure on this?