RyuJIT .NET JIT compiler CTP1 FAQ

RyuJIT .NET JIT compiler CTP1 FAQ

Rate This
  • Comments 44

This post shares more details about our new .NET 64-bit Just-In-Time (JIT) compiler. It was written by Kevin Frei, Development Lead for the CLR JIT team.

RyuJIT received a great response with its RyuJIT: The next-generation JIT compiler for .NET announcement post. Thanks! It was great to see all of the questions. In this post, we’d like to answer your questions and give you a better sense of where RyuJIT is headed.

RyuJIT generates code more quickly. How good is the generated code?

At release, RyuJIT will be both much faster at generating code, and generate code that is as good or better than the current x64 JIT. RyuJIT CTP1 is our first public release of the JIT. Currently, RyuJIT generates code that is roughly similar to the existing x64 JIT. We've been focused strictly on correctness. Yes, we have some code optimizations enabled, but we haven't spent much time tuning for quality yet. We are working on that now, and expect to deliver a future CTP that delivers more optimizations. 

Is Feature X supported? Will it be supported?

We are close to, but not quite at, feature parity with the current x64 JIT in .NET 4.5.1. We plan to match the x64 JIT feature-for-feature when we ship RyuJIT as the JIT compiler in .NET.


  • Tail call elimination: RyuJIT CTP1 supports IL tail-prefixed calls (used a lot in F#), but we do not yet support "opportunistic tail calls".
  • Edit & Continue: We do not yet support it, so if you're using Visual Studio 2013 with RyuJIT CTP1, you'll find that it's falling back to the current x64 JIT frequently, because that's what RyuJIT does when it sees a feature that it doesn't yet support. This is in the works, and will be in the next CTP release.
  • NGEN: We do not allow RyuJIT CTP1 to generate NGEN images. NGEN images, particularly for the .NET Framework, are used by many apps on your machine, like Visual Studio. CTP1 is solely intended for trying out RyuJIT with your app code. Inside of the CLR team, we use RyuJIT as both the JIT compiler and the NGen compiler for our x64 daily builds & testing.

Do you plan to support other features?

We do! We hope to be able to deliver some very exciting features that people have been asking for over the years. So keep giving us your suggestions and feedback: we’re listening! Just email us: RyuJIT@microsoft.com. You can also post and vote on suggestions on .NET UserVoice.

I have a piece of code that is really slow on JIT64. Is it now fixed?

Send it to us to test! We may even blog it as an example if that’s OK. We know of a number of slow algorithms in JIT64, some of which are O(N^2) for both time & space. We’d love to demonstrate that RyuJIT is a big step forward over JIT64.

Will RyuJIT replace JIT32 and JIT64 codebases? What about x86 and ARM architectures?

Yes, RyuJIT is our new JIT compiler codebase going forward.  We’re focused on getting a first architecture complete, which is X64. After that, we’ll need to talk with customers, including internal ones, to determine the order of the other architectures. We know that x86 is high on everyone’s lists.

Why Windows 8.1/Windows Server 2012 R2 only?

We chose to focus our engineering effort on the latest OS, in order to deliver RyuJIT sooner. During the CTP phase, RyuJIT will be supported on Windows 8.1 and Windows Server 2012 R2. Once we have finished building RyuJIT, we will expand the set of supported OSes.

Why now? X64 isn’t new.

RyuJIT is much more than an X64 JIT, but is headed towards becoming the single JIT code-base for .NET. We saw the need to build RyuJIT several years ago, knowing that we needed a single JIT code-base to support a common set of JIT compiler features across multiple processors.

Over the last few years, the JIT team has also delivered other JIT updates. One of those was the MDIL (Triton) compiler for Windows Phone 8. For the last year, we’ve been able to focus on RyuJIT, allowing us to get to the point of publishing a CTP.

When is the next CTP coming?

RyuJIT CPT1 has already been updated, as of early November. A small hand-full of bugs (5) were reported from folks testing RyuJIT, which have been fixed in the update. Thanks! We sent mail in response to all of the bug reports we received, with early access to the updated CTP. Please keep those bug reports coming.

If you previously tried CTP1 and found issues, but did not report them, please try the updated RyuJIT CTP, and report issues that still repro.

Why RyuJIT? How was the name chosen?

Compiler developers and many computer science college students will be familiar with the canonical compiler book referred to as The Dragon Book. Ryū in Japanese means “dragon” so RyuJIT is the “dragon JIT”. As a team, we’re also looking forward to yelling "Hadouken!" when we finally ship.

You can help – tell us which feature to prioritize

We see requests for a lot of different features, some more popular than others. Vote on the ones you care about! The best way to get your feature to the top of the list is to give us scenarios. You want SIMD? What about code quality? What kind of benchmarks should we be tracking? Got a favorite code sample you’d like to see us testing on RyuJIT daily builds? If it’s a great sample in another language (C++, Java, JavaScript), we can port it to .NET. Send it to RyuJIT@microsoft.com and we'll see what we can do.

I want to know more about RyuJIT!

There is more to come with RyuJIT. Please tell us if there is something specific that you want to know about RyuJIT. Reply in the comments or mail us @ RyuJIT@microsoft.com. You can also talk to us @dotnet.

Leave a Comment
  • Please add 3 and 3 and type the answer here:
  • Post
  • Hi and thanks for your great work!

    With the recent demo at VS 2013 launch (keynote) regarding Native C#, I do not have a clear picture of where RyuJIT really stands. As I understand, RyuJIT is here to stay, correct ?

  • Please consider adding SIMD support, either as automatic vectorization like the C++ compiler does, a SIMD library (i.e. Mono.Simd), or both. See



  • Great news! But do the developers have to do something with Ryu or does RyuJit optimice the apps we upload to the Winwodws Store?

  • Great news indeed. Do you have any plan for open sourcing this JIT Compiler?

  • Same question as anthonyb . We getting mixed messages from the .NET team. At the VS 2013 launch Orville  spoke enthusiastically about the Elimination of JIT. What gives?

  • does it mean that Roslyn will use RyuJit? someday maybe?

    why insist on Jit ?

    why not make something hybrid with aot?

    aot for static and strong type code and use jit for dynamic code

    or do i ask it wrong O_O

  • SIMD +1

  • @anthonyb: Yes, RyuJIT is here to stay. There are a number of places where execution time code generation is still either mandatory, or optimal (or both). As details about Native C# are discussed, the picture should become much more clear.

  • @André S.: Thanks for your feature suggestion. We're working as hard as we can on a large number of code generation features. We're well aware of the SIMD requests (though your added voice helps!)

  • @Fernando Urkijo Cereceda: If you're using RyuJIT, it will just work with store apps, though most of the store apps are 32 bit, not 64 bit. I think you also need to opt in with the Reg-Key method, but I'm not sure: I'll take a look and report back for certain.

  • @Anindya Chatterjee: No, we have no plans to open-source the JIT compiler at this time.

  • @anthonyb, @gawicks: Yes, RyuJIT is here to stay. And that's not inconsistent with the message about native code generation for Windows Store that Orville demonstrated at the VS Launch. What's key here is that different scenarios favor different tools.

    Static (native) code generation is fantastic for device scenarios. That's why we've invested heavily in Windows Store (with Automatic NGen), Windows Phone (with the Triton compiler in the cloud) and the thing that Orville demonstrated at VS Launch. But while static code generation saves the time it takes to JIT compile code on your device, it gives up a lot of flexibility.

    Dynamic code generation is ideal in other scenarios, such as server and enterprise. You can't (reasonably) statically compile every PowerShell script that you use to automate your server. Features such as Reflection Emit and CodeDOM are heavily used in server scenarios. And while device apps normally code against a limited platform API, server applications can run against the entire .NET Framework.

    The .NET team is committed to providing the best solution for each scenario. Static codegen and dynamic codegen (with RyuJIT) are both here to stay.

    Andrew Pardoe [MSFT]

  • @vantsuyoshi: We're working on getting the Roslyn self-build working with RyuJIT (still have some JIT compiler bugs to deal with). We don't insist on JIT, we have a system that is designed around JIT, so we're improving the JIT compiler in that system. We already have something hybrid with AOT called "NGen". RyuJIT works fine as the NGen compiler, but we didn't enable that scenario for public usability for reasons that I could go into, but wouldn't really matter. I'll avoid digging into the religious war of "static vs. dynamic" compilation in the comments section of this blog. Maybe I'll write something up for our codegen blog some time in the future. Thanks for the great question!

  • Hi, I have just a simple question, if you plan to use RyuJIT for compiling Windows Phone and/or Windows 8/WinRT apps in the future? Thanks

  • Can you give some C# examples where vanilla-JIT and RyuJIT generate different x86-64 assembly?

Page 1 of 3 (44 items) 123