9 ms·

RyuJIT: The next-generation JIT compiler for .NET

172 points by darrenkopp 13y ago

jevinskie 13y ago
> It’s not supported for production code right now but we definitely want to hear about any issues, bugs or behavioral differences that you encounter. Send feedback and questions to ryujit@microsoft.com. Even if you’ve figured out the issue or a workaround yourself we want to hear from you. What a nice call to action. They even give you a specific email address to contact instead of something generic like support@microsoft.com
- deleted 13y ago
  [deleted]
- taspeotis 13y ago
  > They even give you a specific email address to contact instead of something generic like support@microsoft.com This isn't that uncommon on MSDN Blogs.
topbanana 13y ago
Excellent. Genuine innovation on a platform many had feared was abandoned. My only regret is the confusing x86/x64 message. Many will interpret perf improvements being due to the 64 bitness of new compiler
- malkia 13y ago
  The other one is that it's available only on 8.1 - I wish 7 was supported too.
- Locke1689 13y ago
  The compiler is not 64 bit. :)
  - freikev 13y ago
    Which compiler are you talking about? The JIT compiler is 64 bit, the C++ x64 targeting compiler is available as both 32 & 64 bit. Roslyn is 32 bit because, well, the x64 JIT is dog slow :-)
    - Locke1689 13y ago
      I was referring to C#, but I may have misunderstood the parent. The C# compiler isn't 64, but unfortunately it's not because of the JIT.
- freikev 13y ago
  Can you expand on what you mean by "confusing x86/x64 message"? I'd love to help clear it up. Are you saying that people will believe that the reason the JIT is so much faster is because it's 64 bits? That's the exact opposite of reality: 64 bit programs tend to be slower, because they have to manipulate more data (all pointers take twice as much space, the Win64 ABI requires a minimum of 48 bytes of stack per non-leaf function, etc...)
  - curiousDog 13y ago
    Do all 64-bit programs tend to be slower all the time though? I'd think it would be faster because you're processing more data per clock cycle. Or is that the x64 JIT hasn't been optimized to take advantage of the latest gen of 64-bit processors (I heard stuff about not making use of the latest Math.Pow a while ago)?
    - freikev 13y ago
      Programs that are pointer-heavy tend to be a little slower. There's really not that much 64-bit arithmetic going on in the average application, so the more data per clock cycle only helps in a particular class of apps. Cryptography tends to do significantly better, for that exact reason. You do seem to be conflating code quality with compiler throughput, though. I'll try to clarify in much more detail in a CLR Codegen blog post soon.
    - groovy2shoes 13y ago
      > I'd think it would be faster because you're processing more data per clock cycle. This is only true if you happen to be dealing with integers larger than 32 bits (rarely in most of today's code). The real performance benefit of x64 has more to do with a larger number of general-purpose registers. More registers allow (but don't guarantee) programs to spend less time accessing main memory, thus gaining some speed.
      - curiousDog 13y ago
        Yes, I knew about the registers. I guess I overestimated the number of applications that involve large number computations.
- taspeotis 13y ago
  > Genuine innovation on a platform many had feared was abandoned. Are you equating .NET in general with Silverlight? Honest question.
  - MichaelGG 13y ago
    No, but the way MS came out with WinRT and excluded existing .NET code from executing on it certainly didn't reassure anyone.
    - taspeotis 13y ago
      Uh... WinRT excluded all existing third-party code from executing on it. EDIT: asveikau has rightly pointed out I have confused two matters.
      - asveikau 13y ago
        Surely you would not confuse WinRT, the API, with Windows RT, the ARM tablet product. Why, these names are totally unambiguous! (Microsoft is not great at naming products.)
        Locke1689 13y ago
        I agree :(
    - jmcqk6 13y ago
      WinRT was definitely a screw-up, but at this point I don't see it really effecting developers that much. WinRT has pretty much failed as a platform. At this point, is it even worth developer time to deliver an app to that platform? If you're talking about apps in the windows app store (so-called metro-style apps or whatever the current name is), then you're right that it meant throwing out a lot of code, but it's not true that all existing .NET code was excluded. It took some rejiggering. But once again, that's only if you want to deliver via the app store.
      - 13y ago
alberth 13y ago
I really hope the StackOverlow team writes up a detailed blog post on the performance benefits of RyuJIT. The StackExchange network must be one of the largest .NET web applications. EDIT: typo
- Locke1689 13y ago
  Meh. Web applications are very rarely CPU bound. Hopefully I'll get around to benchmarking the results on Roslyn, although the results are a little bit biased as we have some incredible perf people working on the product.
  - freikev 13y ago
    My next big perf task is to get the Roslyn self-build as a test for RyuJIT. It's a pretty interesting combination of JIT compiler throughput, and generated code quality.
  - alberth 13y ago
    With all due respect, given that you work at Microsoft ... But this article specifically talks about web applications being a primary use case for the new JIT (RyujiT) >>Quote: "But “server code” today includes web apps that have to start fast. 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.
    - bhauer 13y ago
      I am all for fast web applications. But I think there is confusion—or at least I am confused—about what precisely RyuJIT provides. I know it provides quicker compilation times, which would affect the start-up time for web-apps. But does it also provider quicker-executing code? That is, does it do a better job with its optimization of web-apps' code once compiled? Yes, a quick-starting web-app is awesome for when you need to add or replace nodes to your cluster. But I can usually suffer some warm-up time, even in that scenario. My opinion is that web-apps are disturbingly often CPU bound and what I want most of all is faster web applications. Not in start-up time (that's icing on the cake, really) but in bottom-line request-processing throughput and latency.
MichaelGG 13y ago
While that's nice, what about actual innovation in the CLR, like a more expressive type system? Or access to performance basics, like SSE?
- apetrovic 13y ago
  I don't understand this comment. .NET team isn't one man shop, there's various teams working on various issues. Should JIT team stop working until CLR gets "more expressive type system"? Not to mention that .NET CLR features are mostly driven by CLR languages. While there's couple of things that CLR can do what C# can't do, you can bet that CLR will get new features when they're introduced in new C#. And yes, SSE access would be nice.
  - MichaelGG 13y ago
    You're correct, and my comment isn't constructive. It's just that they added features for CLR2, and then it's stayed there. C#'s been even more stagnant; they haven't even gotten around to polishing the edges from the LINQ push.
millstone 13y ago
How does this relate to the normal .NET compiler? I thought .NET programs were compiled at installation time, not JIT? The reported performance improvements here are significant, but in absolute terms still seem pretty bad. 200 MB to compile a big regex, or 1 second of JIT time during launch, is a substantial burden.
- jsmeaton 13y ago
  The compiler you're thinking of compiles to MSIL - bytecode. The run time still needs to compile the bytecode into machine code, and this is what the JIT is responsible for.
  - millstone 13y ago
    I guess I was thinking of the NGen compiler. My (very vague) memory is that NGen is run at installation time. Is this run after NGen, or instead of it?
    - pjmlp 13y ago
      In .NET bytecodes are always compiled to native code before execution, there aren't any interpretation steps like in other management environments. By default, MSIL gets compiled to native code on load via a JIT compiler. The developers that care about performance on startup, can choose to use ngen at installion time, thus taking the JIT out of the equation. The only issue with ngen is that it isn't able to perform all optimizations that the JIT is capable of. So this new JIT improves the current JIT and most likely, the optimizer will also be used by ngen.
    - freikev 13y ago
      NGen invokes the JIT compiler, so your install time (and .NET servicing time) should be quite a bit lower, once we release RyuJIT as part of the full .NET Runtime. Probably less important, but still important enough for a lot of customers to complain :-)
    - josteink 13y ago
      My (very vague) memory is that NGen is run at installation time As far as I know, ngen is only used if you decide to use it. There's nothing automatic about installed code being ngen'ed.
mbq 13y ago
> It’s literally off the chart! -- I hope they are better at writing JITs than making visualisations.
- apardoe 13y ago
  Mea culpa :) --Andrew Pardoe [MSFT]
NicoJuicy 13y ago
Offtopic: I'm actually glad that a project of MSDN (aka. Microsoft) gets on the top pages on HackerNews. I've been a fan of Microsoft on some things they do (but not all). .Net is one of them (Visual Studio). And i've almost never seen something like this rise up on the popular topics section. At least not with constructive comments like here in the topic. So thanks, HackerNews community, you guys have made my day :)
- BillyMaize 13y ago
  So many on HN treat those that write C# code as a sort of lower class of programmers and I have never understood why. I have been writing HMIs for machinery for over two years now in C# and the .NET framework with intellisense is a great tool for getting the job done. I guess there are some programmers that blunder through their career using only the most mainstream languages but I make sure to work towards learning new languages all the time so maybe I'm just a special case.
  - _random_ 13y ago
    It's good to have competition. Modern open source keeps Microsoft awake. At the same time Microsoft has a lot of structure to offer to enterprise and millions of mainstream developers.
  - NicoJuicy 13y ago
    I don't think it's because of C# as programming language, but mostly because that C# is backed by Microsoft. C# is great and everything that is great should get a chance.. At least, that's how i see it.
  - jbrechtel 13y ago
    I don't think it's the treatment one way or the other of those that write C# code. I think it's just the Microsoft Bubble at work. I think there are just fewer .NET developers here than the other ecosystems. I personally shy away from .NET shops because they seem to be such a mono-culture. --- This is totally off-topic so feel free to downvote into oblivion...
  - 13y ago

172 points by darrenkopp 13y ago

> It’s not supported for production code right now but we definitely want to hear about any issues, bugs or behavioral differences that you encounter. Send feedback and questions to ryujit@microsoft.com. Even if you’ve figured out the issue or a workaround yourself we want to hear from you. What a nice call to action. They even give you a specific email address to contact instead of something generic like support@microsoft.com

deleted 13y ago
[deleted]
taspeotis 13y ago
> They even give you a specific email address to contact instead of something generic like support@microsoft.com This isn't that uncommon on MSDN Blogs.

topbanana 13y ago

Excellent. Genuine innovation on a platform many had feared was abandoned. My only regret is the confusing x86/x64 message. Many will interpret perf improvements being due to the 64 bitness of new compiler

malkia 13y ago
The other one is that it's available only on 8.1 - I wish 7 was supported too.
Locke1689 13y ago
The compiler is not 64 bit. :)
- freikev 13y ago
  Which compiler are you talking about? The JIT compiler is 64 bit, the C++ x64 targeting compiler is available as both 32 & 64 bit. Roslyn is 32 bit because, well, the x64 JIT is dog slow :-)
  - Locke1689 13y ago
    I was referring to C#, but I may have misunderstood the parent. The C# compiler isn't 64, but unfortunately it's not because of the JIT.
freikev 13y ago
Can you expand on what you mean by "confusing x86/x64 message"? I'd love to help clear it up. Are you saying that people will believe that the reason the JIT is so much faster is because it's 64 bits? That's the exact opposite of reality: 64 bit programs tend to be slower, because they have to manipulate more data (all pointers take twice as much space, the Win64 ABI requires a minimum of 48 bytes of stack per non-leaf function, etc...)
- curiousDog 13y ago
  Do all 64-bit programs tend to be slower all the time though? I'd think it would be faster because you're processing more data per clock cycle. Or is that the x64 JIT hasn't been optimized to take advantage of the latest gen of 64-bit processors (I heard stuff about not making use of the latest Math.Pow a while ago)?
  - freikev 13y ago
    Programs that are pointer-heavy tend to be a little slower. There's really not that much 64-bit arithmetic going on in the average application, so the more data per clock cycle only helps in a particular class of apps. Cryptography tends to do significantly better, for that exact reason. You do seem to be conflating code quality with compiler throughput, though. I'll try to clarify in much more detail in a CLR Codegen blog post soon.
  - groovy2shoes 13y ago
    > I'd think it would be faster because you're processing more data per clock cycle. This is only true if you happen to be dealing with integers larger than 32 bits (rarely in most of today's code). The real performance benefit of x64 has more to do with a larger number of general-purpose registers. More registers allow (but don't guarantee) programs to spend less time accessing main memory, thus gaining some speed.
    - curiousDog 13y ago
      Yes, I knew about the registers. I guess I overestimated the number of applications that involve large number computations.
taspeotis 13y ago
> Genuine innovation on a platform many had feared was abandoned. Are you equating .NET in general with Silverlight? Honest question.
- MichaelGG 13y ago
  No, but the way MS came out with WinRT and excluded existing .NET code from executing on it certainly didn't reassure anyone.
  - taspeotis 13y ago
    Uh... WinRT excluded all existing third-party code from executing on it. EDIT: asveikau has rightly pointed out I have confused two matters.
    - asveikau 13y ago
      Surely you would not confuse WinRT, the API, with Windows RT, the ARM tablet product. Why, these names are totally unambiguous! (Microsoft is not great at naming products.)
      - Locke1689 13y ago
        I agree :(
  - jmcqk6 13y ago
    WinRT was definitely a screw-up, but at this point I don't see it really effecting developers that much. WinRT has pretty much failed as a platform. At this point, is it even worth developer time to deliver an app to that platform? If you're talking about apps in the windows app store (so-called metro-style apps or whatever the current name is), then you're right that it meant throwing out a lot of code, but it's not true that all existing .NET code was excluded. It took some rejiggering. But once again, that's only if you want to deliver via the app store.
    - 13y ago

alberth 13y ago

I really hope the StackOverlow team writes up a detailed blog post on the performance benefits of RyuJIT. The StackExchange network must be one of the largest .NET web applications. EDIT: typo

Locke1689 13y ago
Meh. Web applications are very rarely CPU bound. Hopefully I'll get around to benchmarking the results on Roslyn, although the results are a little bit biased as we have some incredible perf people working on the product.
- freikev 13y ago
  My next big perf task is to get the Roslyn self-build as a test for RyuJIT. It's a pretty interesting combination of JIT compiler throughput, and generated code quality.
- alberth 13y ago
  With all due respect, given that you work at Microsoft ... But this article specifically talks about web applications being a primary use case for the new JIT (RyujiT) >>Quote: "But “server code” today includes web apps that have to start fast. 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.
  - bhauer 13y ago
    I am all for fast web applications. But I think there is confusion—or at least I am confused—about what precisely RyuJIT provides. I know it provides quicker compilation times, which would affect the start-up time for web-apps. But does it also provider quicker-executing code? That is, does it do a better job with its optimization of web-apps' code once compiled? Yes, a quick-starting web-app is awesome for when you need to add or replace nodes to your cluster. But I can usually suffer some warm-up time, even in that scenario. My opinion is that web-apps are disturbingly often CPU bound and what I want most of all is faster web applications. Not in start-up time (that's icing on the cake, really) but in bottom-line request-processing throughput and latency.

MichaelGG 13y ago

While that's nice, what about actual innovation in the CLR, like a more expressive type system? Or access to performance basics, like SSE?

apetrovic 13y ago
I don't understand this comment. .NET team isn't one man shop, there's various teams working on various issues. Should JIT team stop working until CLR gets "more expressive type system"? Not to mention that .NET CLR features are mostly driven by CLR languages. While there's couple of things that CLR can do what C# can't do, you can bet that CLR will get new features when they're introduced in new C#. And yes, SSE access would be nice.
- MichaelGG 13y ago
  You're correct, and my comment isn't constructive. It's just that they added features for CLR2, and then it's stayed there. C#'s been even more stagnant; they haven't even gotten around to polishing the edges from the LINQ push.

millstone 13y ago

How does this relate to the normal .NET compiler? I thought .NET programs were compiled at installation time, not JIT? The reported performance improvements here are significant, but in absolute terms still seem pretty bad. 200 MB to compile a big regex, or 1 second of JIT time during launch, is a substantial burden.

jsmeaton 13y ago
The compiler you're thinking of compiles to MSIL - bytecode. The run time still needs to compile the bytecode into machine code, and this is what the JIT is responsible for.
- millstone 13y ago
  I guess I was thinking of the NGen compiler. My (very vague) memory is that NGen is run at installation time. Is this run after NGen, or instead of it?
  - pjmlp 13y ago
    In .NET bytecodes are always compiled to native code before execution, there aren't any interpretation steps like in other management environments. By default, MSIL gets compiled to native code on load via a JIT compiler. The developers that care about performance on startup, can choose to use ngen at installion time, thus taking the JIT out of the equation. The only issue with ngen is that it isn't able to perform all optimizations that the JIT is capable of. So this new JIT improves the current JIT and most likely, the optimizer will also be used by ngen.
  - freikev 13y ago
    NGen invokes the JIT compiler, so your install time (and .NET servicing time) should be quite a bit lower, once we release RyuJIT as part of the full .NET Runtime. Probably less important, but still important enough for a lot of customers to complain :-)
  - josteink 13y ago
    My (very vague) memory is that NGen is run at installation time As far as I know, ngen is only used if you decide to use it. There's nothing automatic about installed code being ngen'ed.

mbq 13y ago

> It’s literally off the chart! -- I hope they are better at writing JITs than making visualisations.

apardoe 13y ago
Mea culpa :) --Andrew Pardoe [MSFT]

NicoJuicy 13y ago

Offtopic: I'm actually glad that a project of MSDN (aka. Microsoft) gets on the top pages on HackerNews. I've been a fan of Microsoft on some things they do (but not all). .Net is one of them (Visual Studio). And i've almost never seen something like this rise up on the popular topics section. At least not with constructive comments like here in the topic. So thanks, HackerNews community, you guys have made my day :)

BillyMaize 13y ago
So many on HN treat those that write C# code as a sort of lower class of programmers and I have never understood why. I have been writing HMIs for machinery for over two years now in C# and the .NET framework with intellisense is a great tool for getting the job done. I guess there are some programmers that blunder through their career using only the most mainstream languages but I make sure to work towards learning new languages all the time so maybe I'm just a special case.
- _random_ 13y ago
  It's good to have competition. Modern open source keeps Microsoft awake. At the same time Microsoft has a lot of structure to offer to enterprise and millions of mainstream developers.
- NicoJuicy 13y ago
  I don't think it's because of C# as programming language, but mostly because that C# is backed by Microsoft. C# is great and everything that is great should get a chance.. At least, that's how i see it.
- jbrechtel 13y ago
  I don't think it's the treatment one way or the other of those that write C# code. I think it's just the Microsoft Bubble at work. I think there are just fewer .NET developers here than the other ecosystems. I personally shy away from .NET shops because they seem to be such a mono-culture. --- This is totally off-topic so feel free to downvote into oblivion...
- 13y ago