Coffeehouse Thread

8 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

.Net in Windows Phone 8 - What changed?

Back to Forum: Coffeehouse
  • User profile image
    BitFlipper

    OK so WP8 gets native support. That is a good thing I guess in the sense that it makes it easier to port games etc to it (however I question that this is such a big issue since porting from iOS to Android would be a similar large task, no?).

    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?

  • User profile image
    cbae

    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.

  • User profile image
    vesuvius

    @cbae: I went for a single core phone because of the horror stories of the Samsung Galaxy S2. (dual && quad core phones) == battery muncher.

  • User profile image
    magicalclick

    @vesuvius:

     

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

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    felix9

    I think that will be the 'CoreCLR' flavor of CLR 4.5, so they have the same GC, and hopefully the CloudJIT/MDIL stuff can optimize the native code more aggressively.

    We need to know more about Triton.

  • User profile image
    AndyC

    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.

  • User profile image
    blowdart

    , 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.

     

  • User profile image
    AndyC

    , 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.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.