Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

For Crying Out Loud, Compile for Native ARM!

DZone's Guide to

For Crying Out Loud, Compile for Native ARM!

With the various changes going on in the Windows and ARM worlds, let's see the various performance considerations that could affect your decisions.

· IoT Zone ·
Free Resource

Let me get this straight first: Microsoft did an amazing job with CHPE and x86 emulation, which allows x86 to run without any conversion on the new Windows 10 on ARM PCs. Considering what happens under the hood, the performance and reliability x86 apps get is nothing short of stunning. And you still get the amazing battery life we are used to from ARM – but now on full-fledged PCs.

Yet, there are still some things to consider. If you are a UWP developer, you by now probably have stopped providing ARM packages for your UWP apps. After all, Windows 10 Mobile is, alas, fading away, and these ARM PCs run x86 apps, so why bother?

But Magic Comes at a Price

Well, this is why. UWP can compile to native ARM code, and now we have these ARM-based PCs. Native ARM code can run on the Windows 10 on ARM PCs without using CHPE. Although CHPE is awesome, it still comes at a price – it uses CPU cycles to convert x86 instructions to ARM instructions and then executes those. Skip one step, you gain performance. And depending on what you do, you can gain a lot of performance.

To show you I am not talking nonsense, I actually compiled my HoloLens/Mixed Reality app “Walk the World” not only for x86 (which I need to do for HoloLens anyway) but also for native ARM. I made two videos — of the app running as x86 UWP and native ARM UWP.

Since I don’t use a headset in this demo, I created a special Unity behavior to control the viewpoint using an Xbox One Controller. I keep the actual PC out of the videos again, but you can clearly see the Continuum dock I wrote about before – I connected the Dell monitor using a DisplayPort, the Xbox One controller using USB, and a USB-to-ethernet dongle to rule out any variations in Wi-Fi signal.

First, watch the x86 version:

Then, the ARM version.

You can clearly see: Although the x86 version works really well, the native ARM version starts faster, and also downloads the map faster – considerably so. Still, CHPE amazed me again by the fact that the graphics performance was nearly identical – once the map was loaded, panning over it happened at nearly identical speeds. But apparently, startup and network code take more time. So there’s your win!

Note: Any flickering or artifact you see are the results of the external camera I used, just to prevent any suggestion of this being faked. I also did not want to use a screen capture program as this might interfere with the app’s performance.

Message clear? CHPE is to be used for either x86 apps from the Store that are converted using the Desktop Bridge, or non-Store apps that are downloaded ‘elsewhere’ – think of Chrome, Notepad++ – anything that has not been converted to UWP yet or processed via the Desktop Bridge.

One Extra Checkbox to Rule Them All

I did not have to change anything to my code just to add the native ARM version. Basically, all I had to do was tick a checkbox:

image

…and the store will do the rest, selecting the optimal package for your user. That one little checkbox gives your app a significant performance boost on these Windows 10 on ARM PCs.

Now one might wonder – why on Earth would you convert an app that started on HoloLens to a UWP desktop app to run on a Windows 10 on ARM PC and how you make it work? Well, stay tuned.

And incidentally, this was the 300th post on this blog since I started in October 2007. And rest assured – I am far from done.

Topics:
iot ,native arm ,windows 10 ,performance ,tutorial ,compiling

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}