RyuJIT: The next-generation JIT compiler for .NET
blogs.msdn.com
blogs.msdn.com
What a nice call to action. 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.
The StackExchange network must be one of the largest .NET web applications.
EDIT: typo
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.
>>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.
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.
Reading the article, it sounded to me like Microsoft's primary motivation was cutting back on their development costs by shrinking the codebase. Faster compilation was just a nice side effect that also happened to make for a sexier selling point.
Think, for example, about gene sequencing: JIT compile the app once, chew on data for hours. No one cares too much about the startup time because the app will be running far long enough to amortize the cost of a thoroughly optimizing compilation.
The classic server app of today is often a web app that doesn't do a ton of work relative to its startup time. Web apps often start up, do a bit of work, then shut down. Waiting a long time for the JIT compiler degrades each launch significantly.
As others point out, there are solutions to making web apps faster. But rest assured: RyuJIT helps all kinds of apps: server, client, web, computational.
--Andrew Pardoe [MSFT]
A shorter ramp-up time is always welcomed but JIT is not the only cost. Depending on your application, JIT might not even be the highest/longest portion of your startup time.
Yep.
The simplest way to get this is add a line to the end of the deploy script: "curl http://www.mysite.com/"
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.
Given the number of teams that have succeeded with .Net, I'd say that organisational failings are to blame for this one. Have you already forgotten the reputation of the consultants hired to implement it?
Currently, I think it failed thanks to the usual quality of outsourced projects with off-shoring developers than tooling.
Of course it is always easier to blame the tools.
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 :)
C# is great and everything that is great should get a chance.. At least, that's how i see it.
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...
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.
Oh I agree! Writing HMIs for machinery can be very boring work, but someone has to do it, and since we pick the PCs for the machine we can simply choose windows and then we have no issues being bound to the Microsoft stack. I figure once I get more experience I can go find one of those dream jobs where I can use lots of different languages on a regular basis.
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).
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.
My only regret is the confusing x86/x64 message. Many will interpret perf improvements being due to the 64 bitness of new compiler
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.
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.)
Being a good OS citizen and sticking to the Win64 ABI also makes some things significantly simpler for the rest of the runtime. An obvious example of where this pays off is native interop (e.g. P/Invoke, COM interop, C++/CLI), but one less obvious example of where this comes into play is actually managed exception handling (which is built on top of the underlying Structured Exception Handling mechanism that Windows provides). Not only does adhering to the unified ABI allow managed exceptions to interop with native exceptions, but it also makes things simpler for debuggers, anything that needs to walk the stack, etc.
Remember, the CLR is really more of an execution engine, and not so much a "virtual machine". We try not to disrupt the architectural conventions of the underlying platform, since we're not trying replace the OS environment itself.
--Henry Baba-Weiss [MSFT]
Are you equating .NET in general with Silverlight? Honest question.
EDIT: asveikau has rightly pointed out I have confused two matters.
(Microsoft is not great at naming products.)
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.
It's hard not to see this as informed by how badly Longhorn failed. Microsoft tried to make .NET the basis of their OS platform during Longhorn and failed miserably, in part because it was simply not built for that. CLR belongs as a layer on top.
[Disclaimer: I used to work at MS. Did not work on the Windows Runtime. These are my personal opinions.]
As far as Longhorn failing, certainly that was both a disaster in management and not just technology. After all, MS Corp felt generics were and impractical academic and theoretical idea that couldn't be properly implemented in a language like C# or the CLR.
What?!
Generics were only added to .NET 2.0, because it wasn't going to be done on time for the .NET 1.0/1.1 releases.
There are papers from the .NET Beta days already describing the way generics could be implemented, but additional work was still needed at the time.
Here's a history by Don Syme, who was one of the main people on this project:
http://blogs.msdn.com/b/dsyme/archive/2011/03/15/net-c-gener...
Quotes:
"But I do want to say one thing straight: Generics for .NET and C# in their current form almost didn't happen: it was a very close call, and the feature almost didn't make the cut for Whidbey (Visual Studio 2005)"
"being told by product team members that "generics is for academics only""
"It was only through the total dedication of Microsoft Research, Cambridge during 1998-2004, to doing a complete, high quality implementation in both the CLR [...] and the C# compiler, that the project proceeded."
(I still think C#'s the best out of the "mainstream" languages, but they could be doing a whole ton better.)
As for MSR vs MS Corp, as you put it.
It is called Microsoft Systems Research, it is still a Microsoft unit, with researchers on Microsoft's payroll.
So it is plain and simple, Microsoft.
You can target WinRT with the usual set of .NET languages, the only difference being the classes one uses.
Does C stop being C, if you don't use libc?
Which was cleared for anyone that cared to access the information available after the BUILD conference.
But hey, it is easier to form opinions based in twitter spread rumours, or something like that.
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.
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.
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.
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]
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.