RyuJIT: The next-generation JIT compiler for .NET

http://blogs.msdn.com/b/dotnet/archive/2013/09/30/ryujit-the-next-generation-jit-compiler.aspx

by darrenkopp • 13 years ago

172 80 13 years ago

blogs.msdn.com

jevinskie• 13 years 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

taspeotis4• 13 years 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• 13 years 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• 13 years ago

The other one is that it's available only on 8.1 - I wish 7 was supported too.

Locke16895• 13 years ago

The compiler is not 64 bit. :)

freikev6• 13 years 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 :-)

freikev6• 13 years 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...)

curiousDog2• 13 years 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)?

MichaelGG7• 13 years ago

Why can't the CLR come up with their own "X32" target? IIRC, they made the default for projects in VS to be 32-bit explicitly because of better codegen and lower overhead. If an app is OK with 4GB of RAM, why not let the process run in 64-bit mode, but use 32-bit pointers?

Also, why should the Win64 ABI constrain everything? Certainly it'd only be needed around the edges, but for .NET code calling other .NET code, you're free to do interesting things. (Like pass a GUID or tuple in a single register if it'd help.)

taspeotis4• 13 years ago

Genuine innovation on a platform many had feared was abandoned.

Are you equating .NET in general with Silverlight? Honest question.

MichaelGG7• 13 years ago

No, but the way MS came out with WinRT and excluded existing .NET code from executing on it certainly didn't reassure anyone.

alberth2• 13 years 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

Locke16895• 13 years 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.

freikev6• 13 years 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.

alberth2• 13 years 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.

darrenkopp• 13 years ago

While you may be right when talking about the entire life time of the website, the JIT cost for startup on large asp.net sites can be non-trivial

joseph_cooney2• 13 years ago

I'd be surprised if StackExchange was in the top 100 largest .NET web applications (I guess it depends how you define size, but I've seen apps with much larger code bases, bigger infrastructure, and bigger data sets, and I live in a relatively small country).

taspeotis4• 13 years ago

I think it's likely it's one of the top 100 by traffic, but (not to belittle the achievements of the Stack Exchange guys) I'm sure there's at least 100 bigger sites out there by code/infrastructure.

Flight booking systems come to mind. I don't know how many web applications Microsoft would have individually (I imagine they use .NET...) and whether you want to count those (microsoft.com, bing.com, accounts.live.com, Azure...). Not to mention in-house web applications.

spongle2• 13 years ago

StackOverflow is tiny. We have about 6 million LoC of C# across our entire product portfolio...

NicoJuicy4• 13 years ago

Tiny? Let's agree with that. But StackExchange is one of the most open "platforms" of .Net, and that's why its popular (at least for me, and i'm a .net developer)

MichaelGG7• 13 years 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• 13 years 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.

MichaelGG7• 13 years 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.

millstone2• 13 years 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• 13 years 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.

millstone2• 13 years 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?

mbq• 13 years ago

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

apardoe3• 13 years ago

Mea culpa :) --Andrew Pardoe [MSFT]

NicoJuicy4• 13 years 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 :)

BillyMaize2• 13 years 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_2• 13 years 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.

NicoJuicy4• 13 years 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• 13 years 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...

lmm2• 13 years ago

The C# ecosystem doesn't really interoperate with the HN world. There's a bunch of friction around using it - I don't want to run windows (it's not configurable enough and I'd miss lots of X features), so I'd have to use the relatively weak MonoDevelop, and my dev OS/VM would be different from the production one which would be a recipe for awkward-to-diagnose bugs. There's probably a way to get the software for free but I'd have to start at least thinking about licensing (and that means I can't just fire up a local VM in 30 seconds to test something). Maybe my cloud provider supports windows (though it's unlikely to be as well-tested as their linux infrastructure), maybe not; certainly windows is a second-class citizen for puppet. And what's the library ecosystem like? I get the impression that open-source libraries are a lot less common for .net; is there even an equivalent of cpan/pypi/maven central/etc?

I've got no objection to microsoft/MSDN; I'm a very happy typescript user, because it slots straight into my existing workflow and there's a decent eclipse plugin for it. But for a lot of these things you live in one world or the other, and never the twain shall meet - and rightly or wrongly, my impression is that more interesting software gets written in the "HN stack" than in the "MS stack", which seems a lot more enterprise-oriented.

RyuJIT: The next-generation JIT compiler for .NET

Related Stories