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.)"
Maybe the Haskell team at Microsoft Research really didn't have anything better to do.
Support Eachother, Copy Dutch Property!
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?
Cool, but nobody cares about metro apps or Windows RT. Release it for real computers and we'll talk.
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?"
Finally, a "paid shill" who admits it. I just felt a strange disturbance in The Force, as if millions of forum participants cried out in anger and were suddenly silenced.
Now for bloat at twice, or even three times the speed!
A feeling of having made the same mistake before: Deja Foobar
compiles .NET code to native code using the C++ compiler backend
Can it output the generated C++ source?
A fully compiled binary deliverable! Revolutionary!
(for Microsoft)
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). On the other hand, the startup would benefit - no more need to just-in-time compile. Plus there is no need for memory to compile it. On the other hand, the runtime might use some cycles to further optimize code during execution, whereas with this approach the code won't change any further. In any case, great for instant startup, but I suspect conceptually this is not much different from the older binary pre-compiled cached versions of the assemblies.
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.
Good thing too...
I'm sorry.
I believe this already exists for "real computers". It's called the Native Image Generated (http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx). It's been included with .Net since 1.1.
"It produces performance like C++".
How many times over the years have I seen this? "Widget-of-the-month is almost as fast and efficient as C."
My response is, if the performance is important then why not do it in C? C is definitely as efficient as C. If performance is not important, then why does it matter?
I don't see the need to spend time and/or money on something that's "almost as good as C" when C itself is available.
"This cardboard pizza is almost as good as a real pizza and it only costs $10 more!" Er, no thanks?
If you're a zombie and you know it, bite your friend!
I believe MS Office is built using Visual C++. .NET to build their own applications, presumably because of poor performance.
Microsoft were unable to use
Microsoft have failed to eat their own dog food.
If MIcrosoft .NET was successful, then WindowsRT on an ARM CPU would have not been a failure. .NET was implemented properly, all applications compiled with Microsoft VIsual Studio should have produced exes/dlls with both native x86 and .net (fat binaries). .NET has clearly failed.
If
Then all existing Windows Apps would run on the ARM CPU (admittedly a bit slower).
it ran on linux.
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?
This must be april fools. If they claim it is a .net compiler, but only supports 1% of .net (aka, windows store apps), then this IS APRIL FOOLS!
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.
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.
I both work for MS and read Slashdot
Is there anything positive about yourself that you'd like to tell us. I'd hate to walk away with such a negative impression.
No, what failed was coming up with RT instead of just using .Net (and by that for ARM I mean Mono) to begin with.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
I was hoping that Microsoft was finally starting to die as part of karma for all the bullshit they've done (and continue to do, just more quietly), but it seems this Satya Nadella fellow's new direction for the company is going to result in a new generation of Microsofties that think Microsoft's way is the best/only way and put the foot down on alternatives. C# sounds like a good language, but no-one here uses it and I'm concerned that Microsoft's influence is going to push towards areas that they have no business being in.
That plus the start menu in Windows 8 coming back means Linux will no longer seem like a necessary conversion for many people anymore, plus Office on the iPad and presumably Android in the near future (for free) will result in LibreOffice having almost no users and hence Microsoft will continue to rein surpreme due to dumbfucks who don't know anything about their history!
I have corporations sometimes - the bad ones just won't fucking DIE!
No need to use Mono for ARM. .NET has been supported on numerous architectures, including ARM, as part of Windows CE for years. Sure, it was only a subset of the full framework, but not for any technical reason except keeping the footprint small.
WinRT (not to be confused with Windows RT; we're talking about the API set now) does often feel like a waste of effort to me, although there is something to be said for identifying/creating a sandbox-friendly set of APIs to use in creating sandboxed software...
There's no place I could be, since I've found Serenity...
After all, he'd have to read something that an MS employee wrote.
Quote from the article:
You continue to upload MSIL app packages to the Windows Store. Our compiler in the cloud compiles the app using .NET Native in the Store, creating a self-contained app package that’s customized to the device where the app will be installed.
So it still uses JIT during the development process, only now the NGEN optimization process occurs in the cloud instead of locally.
That's not a sensible usage of caveat. You meant "full disclosure" or "conflict of interest" or some similar. Don't use fancy words you don't know the meaning of.
Sorry, but citation needed. .NET during execution is always native code running against the CPU. The executable is a packed intermediate language that gets cross-compiled to your systems native instruction set when it's run - and for signed libraries, they get stored in a global assembly cache and you don't pay that hit each run. That doesn't mean it's interpreted, it just means the last yard of the compilation is done on your computer.
The closest you'll get to interpreted .NET code is PowerShell. The only bit of your post that's remotely correct is the dependency on the runtime libraries - but that's the same with C++ - and you'll find a lot of people pack that C++ runtime libraries they need with their installers, just to be on the safe-side.
-Steve
.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.
Is this a prelude to allowing compiled desktop applications on Windows RT? Without the CLR overhead, perhaps the ARM would be competitive with an entry-level Intel laptop?
I'm not going back to GW-BASIC, thanks,
But at least we know where M$ started out.
Would you rather they didn't update the assembly cache when they install an update? So your applications have to wait for their dependencies to be updated while they start?
I'd rather have it update the assembly cache in the background after the interruption of a reboot. This way I can run non-.NET applications on one core while the assembly cache updates on another.
Memory and CPU power are there to be used so why not take advantage of it.
Battery life, for one. The less time a task takes, the less energy your application draws from the battery over the course of its running, and the less energy the screen draws from the battery while the user waits for it to finish.
the fact is that in the vast majority of cases saving 5ms while expending 5 times the development effort
For something that takes 20 ms to execute, making it take only 15 ms will help your application update its view every vertical blank instead of every two vertical blanks.
due to NIH syndrome
One cause of NIH syndrome is disagreement with the licensing terms of the pre-existing libraries. Another is that the pre-existing libraries happen not to be ported to a platform that you plan to support.
If you're trying to write something for an 8-bit microcontroller or a retro video game console, a lot of C compilers aren't necessarily competitive with hand-tuned assembly in terms of size or speed of the object code. Or what optimizing compiler targeting the 6502 do you recommend?
No need to use Mono for ARM. .NET has been supported on numerous architectures, including ARM, as part of Windows CE for years. Sure, it was only a subset of the full framework
The .NET Compact Framework can't even run IronPython or any other DLR language because it lacks Emit.
why not do it in C# if it runs fast enough?
Because too many people who code in C# tend to get lazy and not test in Mono.
It won't be. Only the code that'll be required will be included ,others will be shaken out.
never seen the point of c#
#include <sig.h>
And if we coded it all in assembly, it would be even better!
Or how about choosing between a free $10 or receiving $100 for being kicked in the balls. You'd take the $100 ballkick, right?
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
The assembly will be tree shaken, so no there won't be half gigabyte executables.
Actually, generic virtual methods do work in .NET Native.
When MS did the EXACT SAME THING (using a less optimization capable C++ motor behind the executable (less interpreted, & iirc, ONLY forms were interpreted - the compiler didn't do things as well as MSVC++, for instance, in doing loop unrolling))...
Did it work out? Yes, in MOST cases!
I.E. - they did achieve faster running executables (but more memory space consumed initially etc.)
APK
P.S.=> "The more things change, the more they stay the same"... apk
Wow! 60% increase! That's awesome and promising. I hope it also benefits applications which are doing heavy computations (although most of these apps offload their computation to a server).
If any DLL listed in an application's imports section has an hourglass, the app has an hourglass. While an assembly cache rebuild is in progress, the OS can traverse this graph of imports to see what apps need the hourglass.
First let me restate your scenario as I understand it, so that I can be sure we aren't talking about different things. You posit an unmanaged executable starting a child process that is a CIL executable, before the CLR implementation has had a chance to rebuild the assembly cache, without any intervening user interaction (such as choosing an application to run) that gives the operating system a chance to present the CIL executable as temporarily unavailable. And you want the operating system to block the user from starting any executable for tens of minutes at a time just in case it happens to be an unmanaged executable that automatically starts a CIL executable.
If so, I'm interested in your argument as to how this scenario isn't an outlier. What commonly used process would this break?