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?
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?
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.
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.
Good thing too...
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.
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!
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.
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.
But muh metro fart app loads 60% faster!!
I both work for MS and read Slashdot
That's quite OK. Just say three Hail Marys and a P.S. Fuck Beta.
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...
Lies! The Metrosexual UI is the greatest thing ever!
Why is this modded down? Nobody gives a shit about Metro apps running faster -- nobody is writing those nor wants to. Everybody is doing Windows/WPF apps and such. Hell, more command line tools get written in C# than Metro apps. I'll be very excited when this compiler works on real-life software (never?).
You can install .Net from scratch in under 5 minutes. Try again
When installing a security update for .NET takes 45 minutes, there is no pretending involved.
I think it's pretty clear that it taking 45 minutes *is* pretending, that simply does not happen.
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...
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.
I have a Core 2 Duo computer from 2007 and it takes like 5 minutes tops. PEBCAK.
But no one is writing Metrosexual UI apps. That's why Microsoft is having to bundle websites as apps to inflate their app store numbers.
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?
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.
Memory and CPU power are there to be used so why not take advantage of it.
We would like to, but the VMs are stealing away precious CPU time and RAM that could be used for better application performance.
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.
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.
Nobody is pretending, the fact is that in the vast majority of cases saving 5ms while expending 5 times the development effort due to NIH syndrome because you don't want to use pre-existing libraries and creating a huge amount of additional maintenance work is simply not worth it. You could write everything in assembly if you wanted to and with careful optimization you could probably produce faster code but it would take several orders of magnitude faster to do.
It boggles the mind that people *still* use the term "bloated" simply because they are utilizing frameworks that might not be limited to just the exact set of things you need, having the additional functionality rarely produces noticeable performance issues.
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?
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
Two possibilities:
1. You're actually taking about the bug in Windows Update, where patch depth exponentially increases the processing time. There was a /. story a few months ago about this causing multi-hour updates on Windows XP. For most people, the problem goes away if you update Internet Explorer to the latest version first, and then install ALL updates for ALL products. (Note: The bug is not specific to Windows XP; it just has the longest patch chains.)
2. This may also be because most Microsoft installers have an ugly cut-and-paste habit of launching a new CLR process to run a single line of code. When I worked at Microsoft, our dinky little installer did this hundreds of times. It was disgusting, but management tolerated it because the install only took a few minutes (instead of a few seconds like it should have).
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.
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.
and that is the fantasy of people who dont actually have to deal with the real world and get things out to people in any kind of timely manner.
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.
example? you could change those numbers by several orders of magnitude and would make you look even better! those are just random numbers and could be for anything. If the numbers are real and you are comparing actual useful applications then maybe you would have a point but that just looks like random unsubstantiated numbers.
Look at your average iOS application. 20 megs. 50 megs. Or more.
pfft..thats application data, even the ios version of minecraft is only a few megabytes and im sure youll claim its "bloated" and you could do in 32k or some more unsubstantiated bullshit. i love demoscene but the reality is that when you want a functioning, extensible, maintainable codebase that you can implement in an acceptable amount of time you arent reducing everything to the tiniest footprint possible.
your whole thing is just one big rant, show us some evidence, some real-world code that actually proves your theory.
.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.
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
It won't be. Only the code that'll be required will be included ,others will be shaken out.
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.
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.
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).
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.