Enabling RyuJIT in Visual Studio 2015 RC

Question

After installing Visual Studio 2015 RC1, I have loaded a legacy ASP.NET project and changed the .NET version to 4.6. The project works fine, but the website still loads as slow as always. I was expecting RyuJIT to kick in, but apparently it is not.

I've had a look at this thread about RyuJIT and I cannot see any trace of RyuJIT with any of the methods described there.

The same problem also occurs with an empty console project. I cannot see Ryujit in the output window, the Modules window or as a running windows task.

So either RyuJIT cannot be detected as it used to be in earlier previews, or it is not running. Either way, I am stuck.

How can I verify that RyuJIT is running in VS 2015 and what do I have to do to make it run in case that it is not?

Undershoot

You do realise RyuJIT is only 64-bit? Perhaps you running as 32-bit? – Parson

@leppie: I am working on Windows 8.1 x64. In the console project. The "Prefer 32 bit" checkbox is unchecked, so I assume it is using 64 bit. In the ASP.NET project, that checkbox is greyed out, not sure what that means. – Undershoot

There is no option to not use it in .NET 4.6, it is always used to jit 64-bit code. Do not expect a speed improvement, that was not the project's goal. – Hadden

@Hans: Of course it was. MS has been advertising this heavily. One of the many examples : blogs.msdn.com/b/dotnet/archive/2013/11/18/… – Undershoot

That link says improve 64 bit which is coming from a very low level which is a serious issue for more memory hungry apps. – Pollinize

Adrian I dont think your going to see a speed up with ASP.NET , IO costs even at startup are far more heavy than jit / compile costs and the big microsoft libs will have been ngened already. – Pollinize

Answer 1

First, go to the project's settings, Debug tab and make sure that native code debugging is enabled. This enables you to see native as well as managed executables in the Modules window of Visual Studio.

Now run the program in Debug or Release mode and open the Modules window. You will see one of two things:

• Either only clrjit.dll is loaded which means RyuJIT is being used to compile all managed code.
• Or both clrjit.dll and compatjit.dll are loaded which means the legacy JIT64 compiler is being used to compile your managed code while managed code in other executables might use either compiler.

compatjit.dll is loaded when the fallback mechanism is enabled. Otherwise, it's not loaded.

Note that if you installed .NET 4.6 (aka .NET 2015), then RyuJIT will be used by default even if you targeted older versions of the framework.

Regarding RyuJIT vs JIT64. The generated code itself of JIT64 is currently faster than the code generated by RyuJIT. So don't expect performance improvement in this aspect. On the other hand, the compilation time varies. According to Microsoft, the compilation time of RyuJIT can be faster than JIT64 by up to 30% and slower by up to 15%. So don't expect performance improvement in this aspect either.

Things might change a bit, however, when .NET 2015 is released.

Note

If the target platform is "Any CPU", the "Prefer 32-bit" checkbox in the Build tab has to be unchecked. Otherwise, the x86 JIT will be used.

Malnourished

Answer 2

Here you go

After installation, there are two ways to turn on RyuJIT. If you just want to enable RyuJIT for one application, set an environment variable: COMPLUS_AltJit=*. If you want to enable RyuJIT for your entire machine, set the registry key HKLM\SOFTWARE\Microsoft.NETFramework\AltJit to the string "*". Both methods cause the 64-bit CLR to use RyuJIT instead of JIT64. And both are temporary settings—installing RyuJIT doesn’t make any permanent changes to your machine (aside from installing the RyuJIT files in a directory, that is.)

Taken from .NET Framework 4.6 - Testing with RyuJIT

But it should be activated by default

The .NET Framework 4.6 includes new Just-In-Time (JIT) compiler for 64-bit processes, called RyuJIT. It is enabled by default. It is still a preview version, so you may discover issues that have yet to be fixed.

Taken from .NET Framework 4.6 - Testing with RyuJIT

For testing purposes if you encouter any exception with RyuJIT, you can turn it off with a setting in the app.config. This uses the older JIT64.

<configuration>
 <runtime>
  <useLegacyJit enabled="1">
 </runtime>
</configuration>

However, RyuJIT CTP5 currently doesn't work on Visual Studio "14" CTP4. You don't need it anyway, since RyuJIT is enabled by default on Visual Studio "14" CTP4. :) (The version of RyuJIT in Visual Studio "14" CTP4 is slightly older than this CTP, but not by much.)

Taken from RyuJIT CTP5: Getting closer to shipping, and with better SIMD support

I found a Blogpost to determine the used JIT during runtime, but it takes a known bug in den JIT64 compiler into account. The example code is posted here. I am not sure if this is a reliable way to determine it.

Dugong

Thanks for your reply! In that case I wonder why RyuJIT does does not seem to do anything in terms of compilation speed. Do you have any idea why this might be the case? – Undershoot

@AdrianGrigore: No, I´m not sure. What Platform Target is set for your project? AnyCPU, x64? – Dugong

Yes. The project is set to x64, "Prefer 32 Bit" is disabled and the project is is running in IIS on Windows 8.1 x64. Also, if I set the build target to x86, IIS refuses to run it. – Undershoot

Answer 3

RyuJIT activate automatically while you compile the code and this is just a compiler which is run on 64bit mode with access of RAM to boost your compilation 30% faster and time spent in the JIT compiler is only one component of startup time, so the app doesn’t start twice as fast just because the JIT is twice as fast.

you can check your current ram memory status and running process with free available memory if it is enough then it must run faster otherwise there is account of time consider to memory allocation.

Mucus

Compilation times are not reduced since I installed VS 2015 RC either. I'm working on a computer with 16 GB of RAM, with about 5 GB of extra memory available,so I don't think that lack of RAM is the problem. – Undershoot