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.
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.
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.
"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).
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?
I've fallen off your lawn, and I can't get up.
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.
That doesn't sound like a proper native compiler:
The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly.
Yes, it does produce native code.
No, it doesn't produce an executable, ready for redistribution.
I do not disagree with the approach, but there is still the difference. If done right, it might be a blessing: code is optimized for the local CPU. If done poorly (as MS likes to do it sometimes) it might mean irreproducible bugs or performance regressions and outright no effect at all, if cache gets corrupted somehow.
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.
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...
That's where the "preview" part comes in.
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...
I agree with the essence of the statement, but it's written in terms of childish absolutes such as "nobody" that obviously isn't true. Maybe if he had said "The majority of .NET developers aren't doing metro. When you expand support for this feature, then it'll be interesting to the rest of us." But some people live in a world that revolves around them and cry when they get left out. I hope this feature comes to the rest of the .NET platform, but I'm not going to cry about it.
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?
Depends on the hardware. In any case I've noticed that the .NET updates in Windows Update seem to always take the longest to complete out of all the various updates that can appear, so despite they hyperbole there is some truth to what he said.
Compilation doesn't remove the need for a garbage collector.
C#/.NET/MSIL has a plain-old-data (POD) struct type that's allocated on the stack and passed around just like a (non-pointer) C struct. However, Java can only allocate things on the stack when escape analysis proves that something cannot escape.
Yeah, yeah, C# references to structs might have the same escape analysis issue (I haven't used C# in 5 years, so I forget), but at least you know you're doing it. The point is that Java doesn't have the option to declare something that only lives on the stack, so compiled java would still have to churn through memory. :(
Maybe because the plan is to support all of .net.
is expected to apply to more .NET applications in the long term
I assume it was easier to only support the reduced API of metro apps to start with.
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?
1999 called. http://gcc.gnu.org/java/
1) if my app is careful with memory, you have more left to do other things with, and there's less swapping, etc.
2) if my app is 10x faster than yours (and it probably is at least that), I *am* taking advantage of the CPU, in fact, better than you are.
It's an app where you write the code, instead of bringing in a bunch of black boxes. So that A, you can control exactly what is going on, and B, you can fix any bug that arises without having to go to whomever (Apple, MS, Some Random Dude) and beg them to fix their black box. It takes more time to write -- a lot more -- but it results in a much higher quality, easier to maintain software product.
It means just what it says. No black boxes. No compilers that build in overhead with every call and every method, basically nothing that will turn what should be a megabyte of clean code into 100 mb of utter dreck.
I'm not talking about objects in the sense of (for instance) a structure containing slots for various methods appropriate to the concept that the structure implements; that kind of "object" has been around since prehistoric days. I used to code like that in ASM for the 6809. I'm talking about HLL cruft, basically.
As much as is possible to do so, yes. It's the difference between crafting something of your own, something you can service at any level, and something built from Other People's Code, often code you have no control over and/or no knowledge of how it actually works.
AFAIC, someone is capable of real programming when they can write anything they need. And when you can, you should. Because it results in higher quality, more maintainable, faster, leaner products.
I've fallen off your lawn, and I can't get up.
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.
While I agree with you on most points, I don't think the last sentence is warranted -- because people aren't perfect. Just because you can write a piece of code doesn't mean you should. 1) If the problem has been solved exactly like you wanted, and the resulting code has 5 years of bug fixing associated with it, it's probably a good idea to use it (contrived e.g. are you going to rewrite Linux?). 2) Why waste time solving a problem that's already been solved by someone else (assuming it aligns with your specs). Your job is to solve problems, not write code -- computer/code is there to help you solve problems. 3) If you launch a product on the internet with, say, a privacy bug because you wrote that piece of code yourself...well, your company may not be around long enough to fix that bug.
.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.
When your app is going to be used by a billion people, potentially dozens of times a day, every extra millisecond it takes to load costs a man year. Every extra K it consumes costs a terabyte. You should pretend your work will be so popular if you want it to be so popular.
Help stamp out iliturcy.
I'm known to be a low level person and professionally a C programmer. And I agree with you on some stuff.
However...
No, I won't use C to do something in 1k memory and 3 weeks of coding, I will use python in 10mb memory and 1 day of coding. Simply because my time costs more than 10mb of memory. So stop demonising higher level languages and accept that they have their perfectly legit uses as long as their limitations are undestood. Keep in mind that if android used C and not java, we would have about 5 non crashing apps tops in the market.
Sooo, yeah...
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.
NGEN just caches the JIT output of an assembly, it does not produce a native executable.
... whatever
This is actually fucking awesome. They've got native compilation of Win32/64 desktop and server apps on the road-map. You're right, nobody cares about the Windows Store, which is why they targeted those apps first (you know, developers, developers, developers and all that shit).
The FAQ clearly states that they're planning to propagate this feature to all .Net apps.
Desktop apps are a very important part of our strategy. Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications.
I'm guessing that means .Net 4.5+ apps, which in turn means Windows 8+. So here's for hoping that Windows 9 is not gonna suck so much donkey ball, that we can actually expect to be able to upgrade 7 -> 9 without relinquishing part of our soul to the UX demon-child they hired to "improve the user experience".
... whatever
Desktop apps are a very important part of our strategy. Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications.
I'm not your Google bitch, so you can figure out where that quote came from on your own yeah?
... whatever
Some of us are capable of writing anything we need, we just have better things to do than re-invent wheels all the time. Grow up.
... whatever
OK. Your time costs more than 10 MB of RAM. But does it cost more than 10 MB of RAM times 100 apps times one million users? In the latter case, the guys who collectively write the 100 apps are costing the users collectively an extremely large amount of resources (think money).
It depends on how the app is going to be used. I program with C, C++, and Python, as appropriate.
I program on niche embedded devices which have 16mb of ram and still cost a lot of money for what they are. C is the only way there. However through the development circle we have a lot of bugs which get attributed to improper memory management - null dereferencing, memory leaks and the like. This makes the development circle longer, which is acceptable.
Now on the mobile market, it is an implied that the consumer prefers a lot of relatively stable applications in a short period of time. The tradeoff for this is to pay $20 more (probably much less) for the cost of doubling the RAM.
I think in the end, the problem is talent. Talent is scarce. It needs talent to program in C and it needs talent to design RAM modules. However RAM modules are designed once and then produced in an ultra massive scale. On the other side, every little bit of code needs a developer to work on it. And I know from experience that there isn't enough talent in C to produce the loads and loads of software that is currently produced - and even if there was, it would cost. So in the end I think the way it is, is the only way.
> You should pretend your work will be so popular if you want it to be so popular.
No you should not. This is amateur/hobbyist talk. When you have a billion customers, you will have plenty of money to optimize... or by then, you will be able to afford to keep plenty of "terabytes" online. Writing apps for billions of users when all you are likely to have is a few hundred/thousand users... is plain delusional and is inviting trouble.
Highly optimized, hyper-scalable code does not come for free. You will simply go bankrupt before you even get the users to stress your app, if you keep wasting your limited resources (and they are always limited) on imaginary requirements. Keep the architecture clean and follow the wisdom of established design principles. Later optimization will be relatively easy, *if* that need ever arises.
"Premature optimization is the root of all evil" - Donald Knuth.
gcj is largely abandonware since distros adopted openjdk.
(There might still be a case for an AOT compiler to replace hotspot but I'm not sure Excelsior JET has much industry adoption - at least not in the enterprises I worked at.)
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.
All code ends up at one point or another as native code running against the CPU. There may be several stages before it ends up in native code. Interpreters take the code and convert it into instructions the CPU understands on the fly. The fact that .NET gets converted into CIL means that it should be at least partially interpreted. The JIT compiler is the last step that compiles it into native code for the CPU, but this happens before the code block executes. Now, there are technically ways of using the .NET NGEN tool to pre-compile for the system the code sits on, but until it hits the JIT compiler it might as well be an interpreted language (i.e. C# to CIL). This is why they are just now announcing this native compilation tool where it takes out the CIL step completely. Because .NET currently needs to first be converted into byte code before hitting a compiler, I say that it makes perfect sense that it can be considered interpreted at least to the point of the JIT. If my definition of an interpreted language is wrong then I accept that I am wrong. Most of my beliefs on this stance I would base off of the ECMA-335 specification.
So what do you call a programmer who uses NIG? *cough*
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
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
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).
This can only work with precompilation if dynamic assembly loading is disabled (so that the complete set of instantiations is known in advance). This may be feasible for Store apps, but many desktop apps need extensibility.
Put it another way - I'd prefer it if Windows Updates were perhaps more verbose, so I'd know what they're actually doing that's taking so long. For all I know an update is taking too long because it's timed out and failed (which has occasionally happened). At least with Linux the longer updates print a fair amount of messages explaining if they're updating a cache or something.
Wow straight out of 1989.
Modern compilers can probably generate code as fast as you can assemble it. Things have changed a lot in the last 20 years. FYI modern cpus just convert x86 assembly to risc internally. You do not touch the hardware anymore even if you think you do so you loose that efficiency you think you gain.
Let's talk about bloat? How about the bloat of paying you to write code to do something someone can do in half the time with half the experience? That is a bloated pocketbook of lost cash. Sure you can name some custom things which require it but at the end of the day deadlines for that complex business web app need to be finished or people lose their jobs. Java can do this fine with its rich frameworks just as an example.
http://saveie6.com/
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?
Didn't your mother tell you that you should not switch off the computer while it was updating? It's not the fault of Microsoft that you turned off your computer, returned 42 minutes later and expected it to be upgraded.