The world is moving towards 64-bit computing, despite the fact that, as a result, programs do not always run faster or more efficiently compared to 32-bit ones. Many 32-bit programs, for various reasons, can work faster than 64-bit ones. One such example is the 64-bit JIT compiler of the .NET framework. He does a lot of work to make your program work very quickly, but he himself, alas, is not as fast as we would like. This is what we are going to fix. Introducing the x64 JIT compiler of the new generation, which is able to compile 64-bit .NET code 2 times faster.
Talk about x64
It seems that 32-bit x86 computers have been around for a very long time. This is a great architecture that has one big problem: the address space of 32-bit pointers is limited to 4 GB. 64-bit computers with their extended pointers can address a virtually unlimited amount of data. When the first x64 version of Windows appeared, RAM was relatively expensive, so 64-bit machines were in most cases used as servers. Now the x64 architecture has become mainstream and computers are supplied, as a rule, with RAM volumes of at least 4 GB. Even some smartphones have switched to 64-bit processors, despite the fact that they have only 1 GB of RAM.
The .NET x64 JIT was designed to produce the most efficient code during the execution of long running processes running on the server. This is its difference from the .NET x86 JIT, which is optimized for the fastest compilation of IL-code into native code, which ensures a quick launch of programs. Optimization of code efficiency is often justified for server applications. But “server applications” also include web applications, one of the requirements for which is the fastest start. The 64-bit JIT in current versions of .NET rarely boasts a quick compilation of IL-code, which forces many to use other technologies, such as NGen or background JIT.
RyuJIT to the rescue!
RyuWHAT? The .NET Code Generation team is currently working on a completely new x64 compiler with the working name RyuJIT. It works 2 times faster than the current version. This means that the launch time of the programs compiled by him is reduced by about 30% (the time spent on JIT compilation is only part of the application execution process, so the fact that the JIT runs 2 times faster does not mean that the application should speed up as well ). In addition, the new JIT still issues the most efficient machine code.
The graph below shows how RyuJIT is faster than the current JIT64:

Obviously, all the examples worked faster with the new JIT. You may have noticed that the second example (RFC822 e-mail RegEx) literally went beyond the schedule. This is because regular expressions work especially poorly on JIT64. Compiling this example with the JIT64 compiler took 60 seconds and required 1.4 GB of memory. In the case of RyuJIT, it took only 1.8 seconds and 199 MB.
The Paint.NET example came out more normal. Running the application on a test machine was reduced from 2.3 to 1.8 seconds. Compile time was reduced by 1510 ms to 970 ms. I think it is clear that a quick launch with minimal memory usage makes our world a better place.
And for dessert ...
The improved performance and reduced resources used by RyuJIT are great, but it’s not the most exciting thing about it. When JIT64 was first developed, we decided to take the basis for optimizing commands from the C ++ compiler instead of the existing 32-bit JIT compiler, which was better optimized for dynamic compilation scripts. Most 64-bit computers were then used as servers, so it was important to focus on the quality of the compiled code instead of improving the performance of the compiler itself. As a result, the .NET CodeGen team had to maintain the code for two different compilers. Adding features and fixing bugs in two places slowed down the introduction of innovations. And the addition of ARM architecture and MDIL for Windows Phone 8.0 in recent years has made this work even harder.
RyuJIT is based on the x86 JIT codebase. So far it works only for 64-bit architecture. This modernized compiler will later become the basis for all our JIT compilers: x86, ARM, MDIL, and perhaps something else. A common code base means that .NET applications will work as closely as possible across platforms, in other words, the bugs will be the same across different architectures. However, this also means that we will be able to implement new technologies much faster.
')
What you need to do to try it?
The CTP version of RyuJIT is available and you can try it right now in your test environment. There is no support for production yet.
You can
download the RyuJIT installer now, but it only works on 64-bit versions of Windows 8.1 and Windows Server 2012 R2. Note that RyuJIT does not make changes to NGen on your system — we wanted the installation to be clean. And, after RyuJIT is turned on, while writing the “Edit & Continue” code in VS, it will stop working for x64.
After installation, there are two ways to enable RyuJIT. If you want to enable it for only one specific application, add the environment variable “
COMPLUS_AltJit = * ”. If you want to enable it for all applications, then you need to define the key in the “
HKLM \ SOFTWARE \ Microsoft \ .NETFramework \ AltJit ”
registry with the string “*”. Both of these methods force the 64-bit CLR to use RyuJIT instead of JIT64. In addition, both of these methods are reversible - installing RyuJIT does not change anything on your computer (except for placing files in the compiler directory).
Source:
.NET Framework Blog.NET Code Generation Team Blog