RyuJIT: Microsoft's new 64-bit .Net compiler

RyuJIT: Microsoft's new 64-bit .Net compiler

Summary: Microsoft's new 64-bit JIT compiler, codenamed RyuJIT, is now available as a public preview.


Microsoft made available this week for public testing a build of a new 64-bit .Net compiler built by the company's .Net runtime code-generation team.

The new just-in-time compiler is codenamed "RyuJIT."("Ryujin" is the deity of the sea in Japanese mythology.) 

In a September 30 blog post on the .Net Framework blog, Microsoft execs noted there's already a 64-bit .Net JIT compiler. But the new, next-generation X64 RyuJIT "compiles code twice as fast," they claim.

"The 64-bit JIT currently in .NET isn’t always fast to compile your code, meaning you have to rely on other technologies such as NGen or background JIT to achieve fast program startup," acknowledged the post author, Andrew Pardoe, PM Manager for the Common Language Runtime (CLR) Runtime PM team.

RyuJIT is based off of the same codebase as the x86 JIT, according to the blog post. While the Community Technology Preview of RyuJIT is only for x64 right now, it's a "modern" compiler that will "be the basis of all our JIT compilers in the future," including x86, ARM, MDIL (Machine Dependent Intermediate Language) and whatever else comes along." Pardoe said.

"Having a single codebase means that .NET programs are more consistent between architectures—put another way, you generally get bug-for-bug compatibility. But having a single codebase also means we can innovate faster and bring you more code generation features more quickly," Pardoe blogged.

There's no date available as to when Microsoft expects to declare RyuJIT "RTM." But once it is, it will replace the existing Microsoft X64 JIT compiler. It's also worth noting that RyuJIT is intended as a replacement for the .Net compiler only, so it seemingly isn't the coming Microsoft compiler that can compile both C# and C++.

RyuJIT currently only works on 64-bit editions of Windows 8.1 or Windows Server 2012 R2, though this won't always be the case. The RyuJIT installer can be downloaded directly here.

Topics: Software Development, Microsoft


Mary Jo has covered the tech industry for 30 years for a variety of publications and Web sites, and is a frequent guest on radio, TV and podcasts, speaking about all things Microsoft-related. She is the author of Microsoft 2.0: How Microsoft plans to stay relevant in the post-Gates era (John Wiley & Sons, 2008).

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Always good to get a bit of speed boost with app start up

    Although I typically compile with "Any CPU" as the target.
    • Then you'll benefit from this on 64-bit boxes

      This is the second-pass JIT-compiler that takes the output of your C#/VB/whatever compilation to "any CPU" IL and converts the "any CPU" intermediate language code to x64 machine-specific code that actually runs on the box.

      It will speed up the start-up time and warm-up time of your applications.
      • But really, why would I want jit when they could ngen pre download

        they know what the target architecture is. These apps aren't dynamically downloading IL from random parts unknown.
        Johnny Vegas
  • M$ is playing cath up with FOSS

    all FOSS compilers are lighting fast and bug free.
    LlNUX Geek
    • This is not a meaningful comment

      or a meaningful contribution to the discussion.

      The article is quite specifically about the .NET compiler. I am not aware of any evidence that comparable compilers (which would be the Mono and Java compilers) are any faster, or have any performance advantages.

      GCC is probably faster, but it is not a managed code compiler, so that's like comparing the speed of a boat vs. car, or comparing the speed of an elevator and a giraffe.
      • Ugh

        Just bring your giraffe with you on the elevator, stupid.
    • Mono is the FOSS/Linux equivalent to .NET

      It's just about always playing catch-up to Microsoft's tools - since it pretty much follows whatever Microsoft develops.

      I don't doubt that FOSS compilers are good. I'd be *very* surprised if they are "bug free". It's pretty much impossible to write complex systems that are bug-free. Even if you could write "bug-free" code, you wouldn't be able to prove that they are bug free, only that no bugs have been found.

      Even Knuth pays out his $2.56 rewards occasionally.
      • Re: always playing catch-up to Microsoft's tools

        Of course, when you write runtime to Microsoft's specification, you will always "trail" Microsoft, because well -- it is proprietary spec anyway and you can do your thing after Microsoft has done theirs.

        However, the concept that OSS compilers are bad is absurd. GCC is well known for being superior to many commercial products, for decades. Recently, CLANG/LLVM is a cutting edge OSS compiler suite that so far has no proprietary equivalent (and in some cases is significantly better even than GCC).
        There are extremely good single platform commercial compilers as well, for example Intel's ICC, but that is easily explained.

        There is no bug free code, as nobody has the ability to know (all) of the future.
        • "and in some cases is significantly better even than GCC)"

          For a lot more cases it's significantly worse. Two major disadvantages is that it is not as optimized as GCC (with the produced binary) and doesn't support as many archs as GCC.
          • and your point

            ... in relation to OSS trailing Microsoft technologies is?
    • Thanks...

      ...for your anecdote.
    • very pointless

      To say any software of any significance is 'bug free' is a statement made from ignorance.

      To say "ALL" a type of software from a group is bug free is made from raw stupidity.
      • just like that aussi_troll is troll free

  • Edit and continue?

    I wonder if this will finally enable "edit-and-continue" when debugging 64bit projects in Visual Studio.
    • VS 2013

      That's a new feature in VS 2013 unrelated to this.
  • JIT not language compiler

    There isn't a good explanation of this in the article and people commenting are already showing confusion about this: RyuJIT is the MSIL to machine code compiler that runs at application startup (in most cases), not a compiler for high level .NET languages like C# and VB.

    The new language to MSIL compiler (Roslyn) is a separate thing and doesn't have the same separate 32/64 implementation in the current version that exists in the JIT compilers.
    • Yes we get it

      The compiler's very name makes that clear. .NET devs are well aware (from c:\windows\microsoft.net\framework\version\Temporary Internet Files ) that MSIL is all you get from Visual Studio's output.... if we got more, Reflector and ILSpy would not work.
      • Most of the other commenters didn't get it.

        There very comments make that clear, go read them.
    • Roslyn

      Mary Jo wrote:
      "It's also worth noting that RyuJIT is intended as a replacement for the .Net compiler only, so it seemingly isn't the coming Microsoft compiler that can compile both C# and C++"

      You are really misleading here. There are some optimization techniques, such as autovectorization and autoparallelization, used by both C# and C++ compilers. Anders wants to introduce more dynamism from TypeScript into C#, not abandon Roslyn. Anyhow, how could the two compilers share their codebases?

      MJ, you should think for a second before you type nonsense.
  • i thought it was a reference to Ryu Hayabusa

    Mind you, they should personify Visual studio as Ayane