3 ms·

People have done research before into having the C#->native JIT be written in C#, I recall seeing prototypes. There are a ton of barriers between a prototype an

People have done research before into having the C#->native JIT be written in C#, I recall seeing prototypes. There are a ton of barriers between a prototype and a shipping implementation though, so I'm not sure we'll ever see it. In particular you risk regressions in startup time or memory usage since the amount of infrastructure needed to run C# (pre-jitted?) to generate all your jitcode is much higher than a small blob of hand-written C/C++ that's spitting out jitcode. See https://www.mono-project.com/news/2018/09/11/csharp-jit/ https://www.mono-project.com/news/2018/09/11/csharp-jit/ for one example. There's an old saying (from one of Unity's developers, I think?) that you can't run Hello World in C# or Java without an XML parser because so much configuration for things like locales ends up pulling in serialization libraries, reflection, etc. Things have improved in this area for both platforms but it's definitely still very difficult to trim managed code down as far as you can trim native code. For something as critical as the JIT you also want to keep the generated code small (for cache efficiency) and if possible, PGO it - things that existing managed code generators aren't especially great at compared to clang or modern MSVC. From my past experience writing/maintaining C# compiler and runtime code, I would never bother trying to port the JIT to C#. I don't think the returns are worth the massive investment. I'd sooner port it to a language like Rust for safety benefits or to some sort of hypothetical language that enables producing smaller/faster code to improve JIT performance. I'm not sure I'd invest in that either though because for most workloads JIT time is not the bottleneck (and you can optimize that out in many cases by pre-generating the JITcode). EDIT: Also, for workloads where JIT is the bottleneck, it's questionable whether it's possible to extract big gains out of optimizing the JIT because of the nature of JIT workloads - you may just be bottlenecked on memory bandwidth or instructions per clock. A JIT converting IR to machine code is not trivially vectorized. People are figuring this out (again, from scratch) now with webassembly as all the modern browsers go through the churn and angst involved in answering the question 'can we actually JIT this whole 50mb executable from scratch at load time?' even though we already knew the answer back when WebAssembly wasn't a spec yet. [DISCLOSURE: I get paid to work on Mono right now and was paid to help draft the initial WebAssembly spec, and before that my work on the JSIL MSIL->JS compiler was sponsored. So I have some massive biases here.]

chrisseaton 7y ago
The way Java does it is their JIT written in Java is optionally AOT compiled to native code, so it doesn't have a startup time or warmup time problem and it can be PGOd. We do know that the returns are worth it, because people are able to develop new optimisations in the Java version that people just won't attempt in the C++ version because the code is so much harder to work with (but possibly just due to the age of the C++ version) and its achieving 13% speedup over the C++ version in practice at places like Twitter, which is worth millions of dollars.
- kevingadd 7y ago
  This is fascinating. Is the claim here that the C++ version could have never been as fast as the current Java one or just that people have been optimizing the Java one and getting improvements past the C++ one? Also, it sounds like the old C++ JIT has to be maintained and shipped in the event that the Java-based JIT isn't available at startup, right? If so that makes sense as a stop-gap and it would be more of a tiered JIT, not a port. Tiered JITs are definitely proven, successful technology.
  - chrisseaton 7y ago
    > Is the claim here that the C++ version could have never been as fast as the current Java one The claim is that the work to add new optimisations to the old C++ code is so difficult that people aren't prepared to do it. The Java code is easier to write and debug, enough so that people are managing to add new optimisations that they haven't added to the C++ code. > the old C++ JIT has to be maintained and shipped in the event that the Java-based JIT isn't available at startup Well only until the new Java JIT is mature. The AOT build of the Java JIT can be shipped in the binaries so it's always there. > If so that makes sense as a stop-gap and it would be more of a tiered JIT, not a port. Tiered JITs are definitely proven, successful technology. It's used as a new top-tier yes, replacing the C++ top tier. The C++ JIT is likely to go I think, in the medium-to-long term.

chrisseaton 7y ago

The way Java does it is their JIT written in Java is optionally AOT compiled to native code, so it doesn't have a startup time or warmup time problem and it can be PGOd. We do know that the returns are worth it, because people are able to develop new optimisations in the Java version that people just won't attempt in the C++ version because the code is so much harder to work with (but possibly just due to the age of the C++ version) and its achieving 13% speedup over the C++ version in practice at places like Twitter, which is worth millions of dollars.

kevingadd 7y ago
This is fascinating. Is the claim here that the C++ version could have never been as fast as the current Java one or just that people have been optimizing the Java one and getting improvements past the C++ one? Also, it sounds like the old C++ JIT has to be maintained and shipped in the event that the Java-based JIT isn't available at startup, right? If so that makes sense as a stop-gap and it would be more of a tiered JIT, not a port. Tiered JITs are definitely proven, successful technology.
- chrisseaton 7y ago
  > Is the claim here that the C++ version could have never been as fast as the current Java one The claim is that the work to add new optimisations to the old C++ code is so difficult that people aren't prepared to do it. The Java code is easier to write and debug, enough so that people are managing to add new optimisations that they haven't added to the C++ code. > the old C++ JIT has to be maintained and shipped in the event that the Java-based JIT isn't available at startup Well only until the new Java JIT is mature. The AOT build of the Java JIT can be shipped in the binaries so it's always there. > If so that makes sense as a stop-gap and it would be more of a tiered JIT, not a port. Tiered JITs are definitely proven, successful technology. It's used as a new top-tier yes, replacing the C++ top tier. The C++ JIT is likely to go I think, in the medium-to-long term.