Original URL: http://www.theregister.co.uk/2014/05/02/arm_test_results_attack_intel/

ARM tests: Intel flops on Android compatibility, Windows power

Cambridge lab rat's verdict: 'We're still beating 'em'

By Rik Myslewski

Posted in Hardware, 2nd May 2014 20:59 GMT

ARM has rolled out a battery of test results that fire two shots across the bow of Intel's x86 dreadnought now sailing into Android waters.

The first set of results addresses the fact that when running native apps that haven't been recompiled to run on Intel-based Android devices, those apps need to be emulated using "binary translation," which converts native ARM code into native Intel x86 code.

Intel says that users shouldn't worry – its binary translator will "just work" with "very minimal power implications" and "unnoticeable performance impact for most applications." ARM – as you might expect – would beg to differ.

"Binary translation – despite what you may have read or despite what you may hear – does have a huge impact to the user and to the performance of the system," ARM senior technical marketing engineer Rod Watt told attendees at his company's 2014 Tech Day this week in Austin, Texas.

Watt based his conclusions on tests he ran himself, and on benchmark and game-performance test results (Google Translate) he obtained from the Chinese-language website 爱搞机 – which Translate rather less than helpfully renders as "Love to engage in machine."

Before testing performance and power consumption, Watt first checked to see how many popular Android apps need to be translated in order to run on an x86-based Android device. To do so, he twice checked out 100 apps: the top 25 free and paid apps and the top 25 free and paid games in the online Google Play store.

Watt was only concerned the performance of apps containing native code. But it's worth noting that only around 20 per cent of the 100 apps he surveyed ran exclusively on Android's Dalvik virtual machine; the rest contained at least some native components.

What he found was somewhat surprising. Despite the relative ease of porting 32-bit ARMv7 Android apps to native x86 apps using the Android Native Development Kit (NDK), his July 2013 check-up revealed that 42 per cent of those popular apps still required binary translation to run, and that number rose to 44 per cent by January of this year.

ARM Power and Efficiency Analysis presentation slide: x86 Android App Compatibility – USA

How's that x86 Android app transition going, Intel? (click to enlarge)

What's more – and remember, these are Watt's numbers, not something The Reg has confirmed – the number of native x86 Android apps among those 100 most popular dropped from 30 to 23 per cent during the same period, and the number of apps that failed to run at all using binary translation rose from 6 to 9 per cent.

Of course, there could be any number of reasons why a developer might choose to not bother to use the Android NDK to port their app to x86 – verification time and trouble, for example – but Watt has a more-straightforward analysis. "It's an ARM world," he said. "Developers are writing for ARM; they're not writing for Intel."

Maybe those developers writing for ARM should rethink their decisions not to port their apps to x86 Android, if the performance numbers that Watt shared from 爱搞机 are anywhere near accurate.

The Chinese testers ran a series of benchmarks and the Android game Epic Citadel (Unreal Engine 3) on a Lenovo K800 smartphone powered by an Intel Atom Z2460, running them in both native and binary translated mode.

To say that binary translation induced a performance hit in the testing 爱搞机 conducted would be a gross understatement. As Watt pointed out, benchmarked performance was down by 60 to 80 per cent in nearly every measure.

ARM Power and Efficiency Analysis presentation slide: Binary Translation – Performance Impact

Poorer performance and a higher power draw, 爱搞机 says (click to enlarge)

In addition, not only did their Epic Citadel testing show a drop in average frames per second from 49.5 to 31.2, it also indicated that running in binary translation mode increased the percentage load on the CPU from 58.9 to 73.4, and the current draw from 621 to 717 milliamps – not good news for your smartphone's battery life.

It's that damn translation overhead, one assumes. In point of fact, Watt pointed to the effect of binary translation overhead when running various components of Primate Labs' Geekbench 3.1.4 benchmark suite both in native ARMv7 mode and using binary translation to run the suite on x86.

The results weren't pretty: when using binary translation on this CPU-centric benchmark, power consumption went up nearly 90 per cent and performance dipped by over 40 per cent.

ARM Power and Efficiency Analysis presentation slide: Overhead of Binary Translation

As might be expected, emulation through binary translation is a power hog (click to enlarge)

All of his testing of binary translation, Watt said, shows that it "does all the things wrong that you'd want in a tablet. It lowers your performance. It messes up your frames per second and makes things jump. It takes longer to load your application. It reduces your battery life. Basically it does everything wrong that you'd want in a tablet."

Watt What about power hunger 'in Intel's back yard?'

But Watt didn't stop at dissing binary translation. He also wanted to compare ARM versus Intel compute-core efficiency, so he loaded his test bench with a Asus Transformer Book T100 powered by a 22nm quad-core Intel Bay Trail Atom Z3740 running at 1.86GHz, and a Nokia Lumia tablet – presumably a 2520 – with a quad-core 28nm Qualcomm Snapdragon 800 with Krait 400 compute cores.

Through a nifty bit of hardware hackery, Watt said, he was able to isolate the power going to both SoCs, and measure their consumption. He chose to test the entire SoC, he said, because power claims for just the CPU, just the GPU, or just the video engine can be misleading, seeing as how it's the entire SoC that needs to be taken into consideration. What's more, different vendors may configure and identify, for example, power-hungry caches for CPU and GPU, which can distort results.

The T100 was running Windows 8.1, and the Lumia Windows RT. "We're very much in Intel's back yard here," Watt said. "We're running Windows, which Intel obviously has a long history of running and making it very efficient." Despite that advantage, the 22nm Bay Trail drew noticeably more power than did the 28nm Snapdragon, even though the smaller process should have improved the Intel part's power consumption.

Watt first checked the power draw when running the Kraken, SunSpider, and Octane Javascript benchmarks, each in Internet Explorer. The Qualcomm Snapdragon consistently beat the x86 Intel Bay Trail Atom, with power draw averaging about 30 per cent lower.

"The performance is not as high as we're seeing in the Intel device," Watt admitted, "but again the tests are running under a Windows environment, but you can see in terms of efficiency, we're getting much lower power."

Benchmarks are all well and good, he said, but what a user really wants to know is what battery life will be when running real-world applications on an ARM-based tablet versus an Intel-based tablet.

To find out, Watt ran five different tests: opening the fitbit.com home page for 10 minutes, playing YouTube video, fiddling with Google Maps – a test he admitted was the least precisely repeatable of the five – and playing an introductory movie in Halo and a test movie from Big Buck Bunny.

ARM Power and Efficiency Analysis presentation slide: Use Cases – SoC Power

Even at a smaller chip-baking process, and even when running Windows, Intel (Bay) trails (click to enlarge)

Again the Snapdragon drew less power than the Atom – sometimes a lot, sometimes less so. When The Reg asked Watt what other apps he tested and didn't report on, he swore that those five were the only ones he tested, and that they were picked "at random" and were each run "five or 10 times" to get an average score.

Bottom line number one, Watt said, is that Android apps written using ARM's 32-bit ARMv7 architecture and converted to run on x86 Android on Intel hardware using binary translation suffer from poor performance and long load times, and cause poor battery life.

Bottom line number two is that despite Intel's mobile-processor advances, ARM-based SoC's still draw considerably less power than Intel chips, even when taking into account Intel's long history with Windows optimization and the fact that the Atom he tested was baked in a 22nm process and the Snapdragon in a less power-efficient 28nm process.

Or, as ARM's Watt put it more succinctly, "We're still beating 'em." ®