Anyway, so while we can now do games etc in native code, how about performance? I'm asking because .Net in CE has been known to have performance problems compared to .Net in Windows (this is even true for Xbox apparently). One of the big issues is the GC in CE is that it has long GC cycles causing long freezes in games etc. .Net on Windows doesn't have this issue so much since it is much more optimized, etc. See this for instance. In fact I wrote a realtime audio application in .Net for Windows and I can get excellent low latency performance (less than 5ms) with no audible glitches even at high CPU usage (it supports native VST plugins).

So my question is... Are we getting these same .Net benefits in Windows Phone 8 now that it is no longer based on CE? Does anyone have any information regarding expected performance improvements when going with native code vs managed code for something like, say, a 3D game engine?

Here's the reason I'm asking... One of my pet projects is a 3D game engine that I started many years ago. It is an ongoing project and initially it was started in the DirectX 7 days as a native 3D engine. Then when XNA came along, I painstakingly ported it over to XNA (and adding support for WP7), making many improvements along the way. Now with the option of going native again, I'm wondering whether it would be worth porting back to native once again (this will be painful - it took a lot of work to port to .Net), so I'm wondering whether sticking with managed will be fine since I'm expecting .Net code to get a boost from no longer being on CE.

Anyone have info regarding this?

Most WP8 devices will be dual core and have more RAM, so you'll have that going for you at least even if efficiency of the NT kernel doesn't pan out.

That's their problem. You are on different OS now.

We need to know more about Triton.

3 hours ago, AndyC wrote

Well the SDK is still under NDA, so I guess the answer is that anyone who knows for sure won't be able to say. However moving away from WinCE allows the full CLR to be used instead of the Compact Framework (which was a lot less optimal) so theoretically at least, you should see behaviour much more in line with the desktop version than before.

The restrictions put in place by the phone security model on CLR classes will still be there though. WP7 wasn't really the Compact Framework.

2 hours ago, blowdart wrote

*snip*

The restrictions put in place by the phone security model on CLR classes will still be there though. WP7 wasn't really the Compact Framework.

Well I was thinking more in terms of proper generational garbage collection etc, rather than having unlimited access to the framework, per se.