

RyuJIT: The next-generation JIT compiler for .NET - darrenkopp
http://blogs.msdn.com/b/dotnet/archive/2013/09/30/ryujit-the-next-generation-jit-compiler.aspx

======
jevinskie
> 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

~~~
taspeotis
> 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.

------
alberth
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
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.

~~~
alberth
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
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.

~~~
twotwotwo
The post's author commented: "Currently, we generate code comparable to JIT64.
Sometimes we're a little better, sometimes we're a little worse. (I'll post
some samples on the codegen blog as I get time) But we're just getting
started, honestly. I expect that we'll be generating better quality code in
almost every situation before we release a full, supported JIT (and I don't
think we're that far away today)." (That said, CPU perf of the JITted code
isn't everything.)

------
NicoJuicy
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
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.

~~~
lmm
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.

~~~
NicoJuicy
An equivalent of maven central, ... is Nuget. Windows is well tested as an
infrastructure, Azure is great and i think you underestimate it's potential.
I've seen PHP developers using Azure because it's more advanced then anything
else on the market (their words, not mine). Windows Server has an optional
GUI, powershell is Microsoft answer to get an advanced terminal, ...

They support open-source libraries, but it's not as popular as eg. gems. But
some are definatly worth mentioning: glimpse, elmah, stackexchange opensource
projects for detecting queries, ... Some of them are on codeplex, but i see
more and more change to the Github community (ps. git is integrated in Visual
Studio 2012 next to TFS).

Monodevelop is not weak, it's just a version later (if c# 5 is out,
monodevelop is at c#4, not "that" important for developping. Want the latest
gimmicks, well yeah, then it is).

Never used Puppet, so is that important? To test something, you can just
publish your project to your server (or Azure if you like), also other party
hosting is possible. You can also publish it on Amazon if you want.

Your comment on "enterprise-oriented" is correct, but mostly because there are
practicly no bugs on the stack... It's fast (compiled to the CLR) and stable
and it's a proven concept.

SQLLite => Local Database Gems => Nuget ActiveRecord => EF Functional
Programming => F#, lambda's, LINQ

But this is a good comment though. .Net (latest versions) shouldn't be used on
Linux at the moment. It could be different if it had more support of the
community though. I think Microsoft tried it first, they see there is some
kind of barrier and now they are (perhaps) letting it go, piece by piece
(don't know for sure).

~~~
lmm
>Azure is great and i think you underestimate it's potential. I've seen PHP
developers using Azure because it's more advanced then anything else on the
market (their words, not mine). Windows Server has an optional GUI, powershell
is Microsoft answer to get an advanced terminal, ...

I'm not saying these things don't exist, I'm saying they don't interoperate.
To get from where I am now to running on Azure/Windows would involve a lot of
changes that would put me in a worse position if C# didn't work out. It's not
something you can just dip in and out of.

------
topbanana
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

~~~
freikev
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
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)?

~~~
groovy2shoes
> 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
Yes, I knew about the registers. I guess I overestimated the number of
applications that involve large number computations.

~~~
groovy2shoes
Or perhaps I underestimated them...

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

~~~
apardoe
Mea culpa :) \--Andrew Pardoe [MSFT]

------
millstone
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
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
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?

~~~
josteink
_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.

~~~
apardoe
Native image generation differs based on the platform. There is automatic
native image generation in Windows: see [http://msdn.microsoft.com/en-
us/library/hh691758.aspx](http://msdn.microsoft.com/en-
us/library/hh691758.aspx) for details. There's also Triton on Windows Phone:
[http://channel9.msdn.com/Events/Build/2012/3-005](http://channel9.msdn.com/Events/Build/2012/3-005).

In the classic Windows Desktop case, however, you're right: you need to NGen
your code yourself or call NGen as a custom action from your installer.
\--Andrew Pardoe [MSFT]

------
MichaelGG
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
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
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.

