Microsoft demos 'Project N' that can increase Windows 8.1 app performance

Microsoft used the Fresh Paint app to demo the "Project N" code program.

Microsoft is working on a new project that could help speed the performance and load times of future Windows 8.1 apps. The project was demonstrated live as part of the company's Visual Studio 2013 launch activities in New York City.

According to ZDNet, the demo used Microsoft's Fresh Paint app for Windows 8.1. Two Surface tablets were shown, one running the regular version of the app, and the other which was developed with a special coding method that involved compiling .NET code to native code directly. The end result was that the Fresh Paint app made with the new code loaded faster and exhibited better performance than the regular Fresh Paint app.

ZDNet claims, via unnamed sources, that the method used to help speed up the app was created under the code name "Project N" at Microsoft. It's not totally clear how this new compiler will be used. The article speculates that Windows 8.1 developers could submit apps to the Windows Store and Microsoft then uses the "Project N" technology to improve the app's performance before they are released to the public.

Microsoft isn't saying much officially on this new technology and there's no word on when it will be formally released, although the article claims it could happen sometime in 2014.

Source: ZDNet | Image via Microsoft

Report a problem with article
Previous Story

Rumor: Kevin Turner reportedly to be next CEO at Microsoft, followed by Elop

Next Story

Microsoft: Indian banks could be at "major risk" if they don't ditch Windows XP

32 Comments

Commenting is disabled on this article.

So, aren't they just optimizing the same way as what already is possible for the programmers if they use Visual Studio Ultimate's build in optimizer?
If it gets better with some new code they should just update VS.
And if so, include it in the VS Express for Windows 8 apps.

As has been mentioned, sounds exactly like ngen, which has been around for years on the desktop side. It doesn't remove the .NET dependency which I don't think this does either?

notchinese said,
As has been mentioned, sounds exactly like ngen, which has been around for years on the desktop side. It doesn't remove the .NET dependency which I don't think this does either?

Maybe, maybe not.

Windows Phone 8 calls NGEN on Microsoft's servers, and sends the native image down to the phone. So you don't have to pay the cost of compiling MSIL to a native image on startup. But all this does is improve the startup time (which also reduces battery usage). The app doesn't perform any better once it's already running.

But Microsoft is also working on a project to send MSIL through the C++ optimizer for native codegen. This will improve not only the startup time, but also the speed of the code, because the C++ optimizer is better than the .NET optimizer.

Mary Jo Foley is assuming that this is the C++ optimizer. However, the response from Microsoft only talks about startup-time. So maybe it's just NGEN.

This is cool, i'm sure the same could be done on WIndows Phone as well. I wonder if it also works for compilig html5/javascript apps

Agreed, this is pretty cool. It might make some alternative browsers respond quicker though, but I doubt the html/js will load any quicker.

I was confused on this at first. Microsoft has always had advance compiler research going on and NGEN is known feature in the .NET world. The MIDL (compile in the cloud) stuff was first done for Windows Phone 8, which was understandable because of the limited device profiles. So it would be assumed that Microsoft could do the same at least for Surface/Nokia based tablets.

Now beyond this things get more complicated, will this eventually cover all .NET profiles, ASP.Net, WPF and the like? Does it eliminate the need for always on garbage collection? Its not too far fetched that they could do it for all .NET profiles but it makes sense for them to target their highest priority, mobile. They first rewrote the XAML engine from the ground up in C++/CX, so the next step to optimize the C# compiler to output a binary equivalent isn't that far off. But with the new WinRT/COM .next type system is it even necessary?

So as a developer I'm pretty excited about this but not clear where this will eventually lead to. With the Java war contained or won, depending which you look at it, can we truly get back to native compilation? Do we still need GC, VM's and managed code? Is COM coming back under the covers?

MetroNative said,
Is COM coming back under the covers?

COM never left. It should leave at some point, but that's the point of frontending the legacy API stack with the Windows Runtime.

MetroNative said,

So as a developer I'm pretty excited about this but not clear where this will eventually lead to. With the Java war contained or won, depending which you look at it, can we truly get back to native compilation? Do we still need GC, VM's and managed code? Is COM coming back under the covers?

COM is alive and well under the covers in WinRT. Yes, we still need managed code. I don't know anyone who left C++ for a .Net language and misses "the good ol' days."

Skwerl said,

COM is alive and well under the covers in WinRT. Yes, we still need managed code. I don't know anyone who left C++ for a .Net language and misses "the good ol' days."

I agree somewhat... VB6 made COM "easy", though to be good, you had to be somewhat of an expert on DLL registration, ProgId's, DCOM and the like. With WinRT as a C# developer, you just have to adhere to some basic rules to become a callable WinRT component. So with that said, with .NET (Microsoft) never going to anything but Windows why not get rid of the VM and always on GC. I know I make it sound somewhat simplistic, the benefits of the .NET runtime and libraries cannot be overstated but native is (in most cases) always faster and more efficient, in terms of system resources (Memory, IO, CPU).

zoharzenica said,
So Metro Apps weren't snappy and fluid...as we were told before.

Not every metro app is .NET based. Contrary to what some might think you can code using native code if you want/can as a developer.

GP007 said,

Not every metro app is .NET based. Contrary to what some might think you can code using native code if you want/can as a developer.

I bet, native code does not run in ARM.

Brony said,

I bet, native code does not run in ARM.

You can write WinRT apps in C++ and target x86 and ARM. When I said native code I meant coding with C++ and not a managed code option like what .NET gives you.

DonC said,
The Mono project have been compiling .NET to native code via LLVM for some time now.

Sounds good, I think the difference here is that, as the article says, MS could do this for developers when they put their apps up on the Windows Store automatically and give everyone the benefits when they install the apps.

Why not make it an option in the compiler so developers can also give this "benefit" to their customers even if they don't chose to make it available through the Windows store? aka stand alone desktop apps

Are you trying to tell me that native code is faster? Try to tell me something we didn't figure out 30 years ago

Rudy said,
Are you trying to tell me that native code is faster? Try to tell me something we didn't figure out 30 years ago

They're not trying to tell anyone of something they already know. They're helping those who know coding natively is much harder. Now they can continue coding on .NET and with the help of this new compiler, their code will be stripped from .NET to native.

CarlDilone said,

They're not trying to tell anyone of something they already know. They're helping those who know coding natively is much harder. Now they can continue coding on .NET and with the help of this new compiler, their code will be stripped from .NET to native.

You're pretty spot on, sounds like you get all the benefits of managed .net coding but with the performance of native without hassles etc. I think it's a win-win at this point.

Rudy said,
Are you trying to tell me that native code is faster? Try to tell me something we didn't figure out 30 years ago

Well, it's definitely faster. But the problem is that not that many developers have that very smart brains to use it properly without issues. Otherwise, we don't even need C++, just simply use assembly language. And problem solved.

GP007 said,

You're pretty spot on, sounds like you get all the benefits of managed .net coding but with the performance of native without hassles etc. I think it's a win-win at this point.

That's correct GP007. I've been waiting for this for a very long time.

Rudy said,
Are you trying to tell me that native code is faster? Try to tell me something we didn't figure out 30 years ago

"Native" is used to mean two very different things.

First, there's native code vs. managed code. The distinguishing feature is whether or not there is a garbage collector. This is not changing -- C# will still be a managed language.

Then, there's native image vs. MSIL. The C# compiler produces MSIL, which has to be compiled into "native" x86/x64/ARM before it runs. This can be done using JIT, which creates a compilation penalty each time the code is run. Or, you can choose to generate "native" images ahead of time, by calling NGEN, so that you only pay the compilation cost one time.

Problem is, the optimizer in the .NET runtime isn't all that great. There is a separate CLR for x86, x64, and ARM -- so each time they added an optimization to one platform, they had to repeat the work on the other two. But the C++ compiler already has a great optimizer. So Microsoft figured: why not send the output of the C# compiler through the C++ optimizer?

This is not about C# becoming native code -- it'll still have a garbage collector, and it'll still be managed code. However, the new optimizer will make better native images for the C# code.

Edited by TomJones, Nov 14 2013, 5:53pm :

So what would you call C++ code using smart pointers (which can be seen as simple garbage collecting) or C++ code using a garbage collector?

I think your definition for managed is a bit off, I would define managed code as code that is run inside some sort of VM or has a need for a JIT.

XerXis said,
So what would you call C++ code using smart pointers (which can be seen as simple garbage collecting) or C++ code using a garbage collector?

I think your definition for managed is a bit off, I would define managed code as code that is run inside some sort of VM or has a need for a JIT.

"Managed code" simply means code that relies on the CLR to execute. The CLR provides not only garbage collection but also thread management, type safety and exception handling among others.

XerXis said,
I think your definition for managed is a bit off, I would define managed code as code that is run inside some sort of VM or has a need for a JIT.

When you NGEN C# code today, then it no longer requires a VM, and it doesn't require JITting. So does that mean that C# already is not a managed language? Of course not.

It's not the bytecode that makes managed code.

Asik said,
"Managed code" simply means code that relies on the CLR to execute. The CLR provides not only garbage collection but also thread management, type safety and exception handling among others.

Yes, exactly. Thanks, you explained it a lot better than I did.

And none of that is changing, either. C# code will still rely on CLR garbage collection, CLR threads, the CLR type system, CLR exceptions, etc. The only difference is in the generation of the native image.

articuno1au said,
Sounds like nGen for .net O.o

Rosyna said,
It actually sounds a lot like PNaCl from Google (http://www.chromium.org/native...n-to-portable-native-client). I wonder if MS is also using LLVM for Project N.

If Mary Jo Foley is correct, then it is not Ngen, nor is it LLVM. Rather, Microsoft is sending the MSIL output of the C# compiler into the Visual C++ optimizer.

That having been said, Microsoft is already pre-compiling Windows Phone apps. And that's not some fancy new compiler backend that's in development. It's just ngen. All it does is improve startup performance, by removing the JIT step. There is no performance improvement during operation.

Edited by TomJones, Nov 14 2013, 5:08pm :

Thank you. I remember those job postings and was excited back then. I wish we could see this in WPF applications as well. I work on a huge, very complex one, and any boost in performance is always welcome.

Its neither. Microsoft Research are working on applying the attributes of the .NET CLR to the hardware and not run it in a virtual CPU / memory. This is old news unless you like watching ugly chicks in videos talking about hardware resource allocation

TomJones said,

If Mary Jo Foley is correct, then it is not Ngen, nor is it LLVM. Rather, Microsoft is sending the MSIL output of the C# compiler into the Visual C++ optimizer.

That having been said, Microsoft is already pre-compiling Windows Phone apps. And that's not some fancy new compiler backend that's in development. It's just ngen. All it does is improve startup performance, by removing the JIT step. There is no performance improvement during operation.


Jurrasic Park, is that you?