.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.)"

Re:Huh?

[Soulskill]

The word 'faster' was omitted. I've updated to fix.

Re:Translator?

[Calavar]

Correct me if I am mistaken, but I'm pretty sure that if they are using the backend they are skipping the lexing and parsing steps and going straight to the generation of the intermediate representation. That would mean that there is no generated C++ code to see.

Re:Ah...

[jafac]

When installing a security update for .NET takes 45 minutes, there is no pretending involved.

Re:So no more .net redistributable?

[PhrostyMcByte]

Yep! From their FAQ:

apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine.

Re:Is JITC finally going to die?

[aberglas]

You miss the point entirely. The vast majority of CPU time in most applications is spent in a relatively few leaf subroutines. What the JIT does is just compile those bits that are found to be CPU intensive.

In tests I had done some time ago with the early compilers, .Net code was actually faster than C implementing the same algorithm. The reason is that it can perform global optimizations, in-lining aggressively. Sure that can be done with C (and you do not even need macros), but it takes extra work, slows down the compiler if too much is put into header files, and programmers usually miss some of the routines that need in-lining.

Modern generational garbage collectors are also faster than malloc/free, and do not suffer fragmentation.

Delaying compilation makes it architecture neutral, same distro for 32, 64bit, ARM etc. What is needed is to cache the results of previous compiles which causes a slight but usually negligible start up penalty.

Compiling all the way to machine code at build time is an archaic C-grade idea that became obsolete thirty years ago for most common applications.