Slashdot Mirror
.NET Native Compilation Preview Released
atrader42 (687933) writes "Microsoft announced a new .NET compiler that compiles .NET code to native code using the C++ compiler backend. It produces performance like C++ while still enabling .NET features like garbage collection, generics, and reflection. Popular apps have been measured to start up to 60% faster and use 15% less memory. The preview currently only supports Windows Store applications, but is expected to apply to more .NET applications in the long term. A preview of the compiler is available for download now. (Caveat: I both work for MS and read Slashdot.)"
Popular apps have been measured to start up to 60% and use 15% less memory.
So they no longer fully start up? Why is that a benefit?
They also open-sourced their new C# compiler:
http://roslyn.codeplex.com/
Natural != (nontoxic || beneficial)
This can only be a good thing as every game I install these days also installs the redistribution files for .net.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
compiles .NET code to native code using the C++ compiler backend
Can it output the generated C++ source?
It actually sounds like gcj.
When all you have is a hammer, every problem starts to look like a thumb.
From the article:
the .NET Native runtime [is] a refactored and optimized CLR
According to the article, the .NET Native runtime is a (not yet complete) implementation of .NET. This means that Wine + .NET Native = a Microsoft-built .NET runtime on Linux. This is good news because this may be a way to take those .NET technologies missing from Mono, such as WPF, and still use them on Linux.
Another reason this is good news is, we're one step closer to being able to develop Windows installers in .NET. Lately I've been using NSIS and it is the most stupid, idiotic language I've ever used. It's been described as a mixture of PHP and assembly.
Another thought: the article doesn't seem to mention it, but judging by the design, the .NET Native compiler may be able to compile any .NET DLLs and EXEs, not just C# ones.
Next up, compiled java that doesn't churn through memory.
Yeah, sorry, GUIs won. Like 20 years ago. You can stop pretending that our multicore processors with 64 gigs of ram can't handle them.
When installing a security update for .NET takes 45 minutes, there is no pretending involved.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Well, the ART preview native compiler on Android 4.4 is on device so it could compile to native on the device, but I expect Google will accelerate that step precompiling on their servers taking into account device characteristics. Microsoft could do that too if they want
I skimmed over the links, but I probably just missed it. So apps take 60% less time to start, and they use 15% less memory. What about run-time performance? How much faster are they when executing?
Many years ago there was an R&D project inside a large tech company. It was exploring many of the hot research topics of the day, topics like mobile code, type based security, distributed computing and just in time compilation using "virtual machines". This project became Java.
Were all these ideas actually good? Arguably, no. Mobile code turned out to be harder to do securely than anyone had imagined, to the extent that all attempts to sandbox malicious programs of any complexity have repeatedly failed. Integrating distributed computing into the core of an OO language invariably caused problems due to the super leaky abstraction, for instance, normal languages typically have no way to impose a deadline on a method call written in the standard manner.
Just in time compilation was perhaps one of the worst ideas of all. Take a complex memory and CPU intensive program, like an optimising compiler, and run it over and over again on cheap consumer hardware? Throw away the results each time the user quits and do it all again when they next start it up? Brilliant, sounds like just the thing we all need!
But unfortunately the obvious conceptual problems with just in time compilers did not kill Java's love for it, because writing them was kind of fun and hey, Sun wasn't going to make any major changes in Java's direction after launch - that might imply it was imperfect, or that they made a mistake. And it was successful despite JITC. So when Microsoft decided to clone Java, they wanted to copy a formula that worked, and the JITC concept came along for the ride.
Now, many years later, people are starting to realise that perhaps this wasn't such a great idea after all. .NET Native sounds like a great thing, except it's also an obvious thing that should have been the way .NET worked right from the start. Android is also moving to a hybrid "compile to native at install time" model with the new ART runtime, but at least Android has the excuse that they wanted to optimise for memory and a slow interpreter seemed like the best way to do that. The .NET and Java guys have no such excuses.
The raw speed of the code might actually diminish since the .net runtime could have optimized it better for the specific environment (CPU model, available RAM, phase of the moon, etc).
MS announced that developers still need to pass hints to the compiler on what architecture, CPU core count, available memory etch, to compile for. You can (cross) compile to multiple architectures.
This technology is already at work when deploying apps for Windows Phone 8: Developers pass IL code to the store, native compilation is performed per device type in the cloud (CPU architecture, OS version, memory, ...) and the binary is passed to the device.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Raw C can be X-able.
It's just plain PITA to do it.
Otherwise, performance of the raw C is overrated. Or better: the developers who benefit most from C performance are the ones who can't algorithms. Also, developing reusable algorithms in C is a major PITA.
All hope abandon ye who enter here.
Microsoft were unable to use .NET to build their own applications, presumably because of poor performance.
Unlikely. MSO is very old. Very likely the source code is poorly documented and not completely understood. Porting that to anything is going to be a major and very risky undertaking.
.NET has clearly failed.
Still clearly better than VB.
All hope abandon ye who enter here.
"After all, the chief advantages of C# isn't really C#, but the .NET libraries."
You can't be serious! C is *substantially* lower-level than C#; you should only use C as a portable assembly language. I've spent decades writing assembly, C, and higher level languages and I'd pick C# over C in an eyeblink for anything that doesn't require access to the bare metal (well, personally I'd pick a functional language, but these days I work in industry...)
I have never seen an unintended buffer overflow problem in C# or Java.
So you've seen intended ones?
Memory and CPU power are there to be used so why not take advantage of it. And what the hell is a hand coded app? Or are you referring to programming against a runtime versus programming directly against the OS? And what does eschewing OO approaches mean? Are you talking about an application that encapsulates all it's functionalities without referencing any external resources or dependencies?
You can't be serious! C is *substantially* lower-level than C#; you should only use C as a portable assembly language.
Why? C is extremely easy to write and has vast amounts of libraries to use.
No. You can't do that unless the platform is locked down hardware wise, and that's not been the case with the major OS's for quite some time now. The best tool -- to date -- for anything serious aimed at a major OS is c. By far. Not C++. not objective c, not C#, not asm ... just c.
No. That's not it at all. I don't care where it was invented; that's a symptom, not the actual problem. The problem is bringing in other people's code results in a loss of maintainability, quite often a loss of focus on the precise problem one is attempting to address, a loss of understanding of exactly what is going on, which in turn leads to other bugs and performance shortcomings. OPC comes into play at multiple levels: attempts to manage memory for you; libraries; canned packages of every type and "handy" language features that hide the details from you. NIH because it wasn't you just *looks* like the problem, but the problem is what NIH code actually does to the end result, and that's a real thing, not a matter of I don't like your style, or some personality syndrome. If the goal is the highest possible quality, then the job has to be fully understood and carefully crafted from components you can service from start to finish, the only exceptions being where it *must* interface with the host OS. Even then you're likely to get screwed. Need UDP ports to work right? Stay away from OSX. Need file dialogs to handle complex selections? MS's were broken for at least a decade straight. Need font routines that rotate consistently? Windows would give it to you various ways depending on the platform. And so on. Better off to write your own code if you can possibly manage it. You know, so it'll work, and if your customer finds an error, so you can fix it instead of punting it into Apple or MS's lap.
I use "bloated" when my version of something is 1 mb, and a friend's, with fewer lines of code, is 50 mb and runs the target functionality at a fraction of the speed, not to mention loading differences and startup differences. It's not just about a library routine that isn't called (well, until there are a lot of them, or if they're very large... linkers really ought to toss those out anyway), it's primarily about waste in every function call, clumsy memory management that tries to be everything to everybody and ends up causing hiccups and brain farts at random times, libraries that bring in other libraries that bring in other libraries until you've got a house of a thousand bricks, where you only actually laid a few of them, and you have *no idea* of the integrity of the remaining structure. Code like that is largely out of your control. Bloated. Unmaintainable. Opaque. Unfriendly to concurrently running tasks.
Look at your average iOS application. 20 megs. 50 megs. Or more. For the most simpleminded shite you ever saw; could have been implemented in 32k of good code and (maybe) a couple megs of image objects. That's what I'm talking about, right there. Bloat. It's that zone where a craft is swamped by clumsy apprentices who think they understand a lot more than they do. Where one fellow creates beautiful, strong, custom furniture, and the other guy buys a 59.95 box from IKEA and turns a few cams. The good news is that there will always be a place for those who can really craft, because there's a never-ending source of challenges where crap just won't do. And despite rumors to the contrary, end users do know the difference -- especially once they've been exposed to both sides of the coin.
I've fallen off your lawn, and I can't get up.
.NET apps compiled for "AnyCPU" will, technically, run just fine on Windows RT on ARM. The reason why you can't actually run such desktop apps is because it is blocked by signature verifier (any desktop app must be signed by MS to run on RT). It's a DRM thing, not a technical limitation.
Oh, and huge parts of Office use .NET these days, alongside the older native code. Ditto for VS, and many other products.
never seen the point of c#
#include <sig.h>
The best tool -- to date -- for anything serious aimed at a major OS is c. By far. Not C++
Not only that, but it must only be written by a true Scotsman as well.
There are many major, serious, projects written in C++.
GCC, LLVM, Firefox, QT, Webkit, the JVM, libre/open office.
In fact GCC recently switched from C to C++. Basically, C++ provides exactly the same machine model as C, except that it gives you a more programmable compiler and richer abstractions. There are very, very few places that it's worth using C over C++, unless you have a thing for writing yet another resizable array implementasegmentation fault (core dumped).
SJW n. One who posts facts.