While we are still waiting for those mysterious Intel Bay Trail based Android tablets to find their way into our hands, we met with ARM today to discuss quite few varying topics. One of them centered around the cost of binary translation – the requirement to convert application code compiled for one architecture and running it after conversion on a different architecture. In this case, running native ARMv7 Android applications on an x86 platform like Bay Trail from Intel.
Based on results presented by ARM, so take everything here in that light, more than 50% of the top 250 applications in the Android Play Store require binary translation to run. 23-30% have been compiled to x86 natively, 20-21% run through Dalvik and the rest have more severe compatibility concerns. That paints a picture of the current state of Android apps and the environment in which Intel is working while attempting to release Android tablets this spring.
Performance of these binary translated applications will be lower than they would be natively, as you would expect, but to what degree? These results, again gathered by ARM, show a 20-40% performance drop in games like Riptide GP2 and Minecraft while also increasing "jank" – a measure of smoothness and stutter found with variances in frame rates. These are applications that exist in a native mode but were tricked into running through binary conversion as well. The insinuation is that we can now forecast what the performance penalty is for applications that don't have a natively compiled version and are forced to run in translation mode.
The result of this is lower battery life as it requires the CPU to draw more power to keep the experience close to nominal. While gaming on battery, which most people do with items like the Galaxy Tab 3 used for testing, a 20-35% decrease in game time will hurt Intel's ability to stand up to the best ARM designs on the market.
Other downsides to this binary translation include longer load times for applications, lower frame rates and longer execution time. Of course, the Galaxy Tab 3 10.1 is based on Intel's Atom Z2560 SoC, a somewhat older Clover Trail+ design. That is the most modern currently available Android platform from Intel as we are still awaiting Bay Trail units. This also explains why ARM did not do any direct performance comparisons to any devices from its partners. All of these results were comparing Intel in its two execution modes: native and translated.
Without a platform based on Bay Trail to look at and test, we of course have to use the results that ARM presented as a placeholder at best. It is possible that Intel's performance is high enough with Silvermont that it makes up for these binary translation headaches for as long as necessary to see x86 more ubiquitous. And in fairness, we have seen many demonstrations from Intel directly that show the advantage of performance and power efficiency going in the other direction – in Intel's favor. This kind of debate requires some more in-person analysis with hardware in our hands soon and with a larger collection of popular applications.
More from our visit with ARM soon!
Forgive my rudeness. When I
Forgive my rudeness. When I first saw the article it only showed the first paragraph for some reason.
Ah, right, I had left out an
Ah, right, I had left out an important item in the post. 🙂
All android apps are compiled
All android apps are compiled into Dalvik bytecode and run on the Dalvik VM that itself runs under the Linux Kernel. The VM/OS itself is what is written in the native code of the processor that it is hosted on. Android by its very nature is a cross platform runtime, and as long as the Apps are compiled into Dalvik bytecode the underlying hardware should be abstracted from any Android software(compiled to Dalvik bytecode).
Its the effiency of the Dalvik VM that Intel developed to run on their x86 hardware that may be in question, that and x86’s higher transistor count compared to ARM refrence based CPUs. Now who has the most efficient JIT(Just in time compiler) that should be what is in question. There needs to be benchmarks to test the Dalvik VM implementation’s effiency from each providor(ARM, Intel, whoever) and its going to be hard to prove without indipendent benchmarks. Also depending on the process node of the CPU hardware, ISA, and what ever bloatware/system software(services) the OEMs have as well as other programable power states the OEM’s can lock the SOC hardware to, will affect the performence.
To make things more confusing there are JIT backends that can run the android applications through a first time compile(JITed)/VM run(“snapshot”), and keep a portion of the application in the native code of the processor, stored in some form of relocatable native object code state or file, so not as much Dalvik VM translation has to be done the next time the application is started. Android apps compiled into Dalvik bytecode, should be portable without any native ISA worries, but the Dalvik VM implementation on every OEMs system will have some customizations, and there is too many layers of hardware abstraction on Android VM implementations to ever trust anything other than a completed device obtained through a random retail purchase, and run through an independent testing lab, with independently certified and compiled benchmarking software. We all Know that any companies’ claims can can not be trusted, Intel’s or any other’s.
edit” “The VM/OS itself is
edit” “The VM/OS itself is what is written in”
to: The VM/OS itself is what is compiled into
Very informative, thanks!
Very informative, thanks!
Great feedback and you are on
Great feedback and you are on point here! If we could get access to a perfectly comparable system the tests would be kind of simple but neither party is really interested in creating platforms built for direct compraison.
If there were the case, then
If there were the case, then ARM would not be able to make native vs binary translated comparisons. The fact is that many apps–expecially performance critical ones–are not all native Java byte code. They often have extensive chunks of ARM native machine code in them. There are a number of reasons for this. For one, it allows an app to better take advantage of the features of various processors. To do that, they use native processor code which, if you try to run it on a different processor will require translation.
So, no, it can’t be truthfully said that Android apps are all just Java bytecode. That is an ideal that has not proven to be as widespread as some believe. With Java, you can ‘write one, run anywhere’ as long as you don’t mind running slowly *everywhere*.
Before anyone starts ragging on developers for sacrificing the ‘run everywhere’ benefits of Java, keep in mind that their code runs on millions of devices–most of which are battery powered. The faster and more power efficiently their code can run provides *direct* benefits to their users. It’s an optimization tradeoff. Does it make more sense to run 25% faster on *millions* of devices if it means running 25% slower on a few thousand?
Yeah, it does. I completely does. Intel knew the situaiton going in–which is why they have a binary translator ready. They knew that, being a small chunk of the market, they would need to put more work into adapting themselves to the ecosystem.
As far as I’m concerned, this ARM presentation tells us nothing that we didn’t already know to be the case, but it’s nice to have solid numbers.
Poor poor MIPS….
Poor poor MIPS….
The first sentence is where
The first sentence is where the error is. Many apps use the NDK and are compiled natively to each CPU architecture. That’s what ARM is talking about.
U got that totally wrong.
U got that totally wrong. What u said is true for java code. Java code doesn’t need any binary translation though.
What this article is about is translating all the apps(mostly games) using native (c/c++) code.
ARM managed to take all this
ARM managed to take all this market share thanks to higher efficiency, much much lower prices and primary thanks to the fact that good enough hardware today, is much more than enough for almost anything.
Now X86 companies are catching up. They will never reach ARM levels in efficiency and they will never manage to sell SoCs at ARM SoC prices, but they will be good enough compared to ARM SoCs having other advantages to offer(Windows/Linux).
ARM was considered a huge threat for Intel in the recent past. Today X86 is becoming a threat for ARMs expansion in bigger devices than phones. In my opinion that’s why ARM is showing these slides.
But do we really care? I think in the end we don’t, for the same reason we don’t care if our PCs calculate SuperPi in seconds and our phones in minutes. For the same reasons we don’t care if out phones use 5W and our PCs 500W.
Arm Holdings is not the only
Arm Holdings is not the only game in town where high performence is concerned, IBM will be licensing its Power CPU IP/ISA(NOT to be confused with the PowerPC line of CPUs). ARM Holdings is most likely responding to some Intel FUD, in this case of ARM vs Intel, but IBM’s power based CPUs are beasts when it come to high intensity computing workloads, and Intel is very afraid, unless they are completely insane! I have stated in many posts, that the Licensed IP business model is going to take over in the computing industry, and Google has a IBM Power8 CPU based refrence server board that they are currently evaluating, and Samsung and GlobalFoundries are members of IBM’s technology foundations/partnerships, along with Nvidia and others. Samsung got Much help through its IBM technology partnership with that 14nm process that it is sharing with GlobalFuondries. IBM is going to be getting out of the foundry business(except for its research fabs/IP), and IBM needs/will need Samsung and GlobalFuondries for its power processor supplies. Expect to see many Power8 based products, running Linux(IBM will be keeping its proprietary Server/Mainframe OS to itself). IBM is loosing Money on the hardware side of the business(Chip Fabs are not cheep, especially when idle), but IBMs real moneymaker is its proprietary server/mainframe OS/services ecosystem, and going mostly fabless will save them billions. Look out Intel, Power8 is out of its corral!
On Line 1 of post,
On Line 1 of post,
Edit “Arm Holdings”
What ARM says is pure FUD. It
What ARM says is pure FUD. It may be true that a large percentage of apps are ARM only, but recompiling them for x86 is trivial. Far as I know the NDK by default targets both ARM and x86, and I suppose that many devs disable this to save time and reduce the app size, but the moment Intel gains entry into this market app makers will flip the switch and produce native x86 versions.
That will indeed be
That will indeed be interesting to see. We really just need one or two moderate wins for Intel in an Android tablet to see if the market shifts.
The most importent thing when
The most importent thing when comparing ARM holdings’ refrence designs to Intel’s competing products is that ARM Holdings does not make any of its designs into actual products, it’s ARM holdings’ licensees that make the actual SOCs, and many licensees such as Apple, only license the ARM ISA(Armv8 ISA, in Apples case for Its A7), and Apple’s A7 is a custom in house Apple design, that is engineered by Apple to run the ARMv8 ISA, and the Apple A7 can retire more IPC(“instructions per clock/cycle) than the Arm Holdings 64 bit refrence designs. The same can be said for Nvidia’s Denver cores, as well as some of Samsung’s and Qualcomm’s SOCs.
There is such a complete level of customization options with the ARM Holdings licenses that are mixed and matched with other companies’ licensed IP that each individual companies’ SOCs must be separately evaluated with an independent benchmark, even for SOC based on the same ARM Holdings’ refrence design. Many OEMs are licensing refrence CPU designs from Arm Holdings, and On die interconnect fabrics for other third party IP houses, and GPUs from other design houses, so this and the OEMs, like Apple/others that make their own custom designed CPU cores, make the process of comparing different companies’ SOCs like rocket science.
A x86 tablet doesn’t need
A x86 tablet doesn’t need Android.
Tablet x86 + Windows = Tool
Tablet ARM + Android = Toy
Tablet ARM + iOS = Expensive Toy
The Apple A7 Cyclone core is
The Apple A7 Cyclone core is nothing to be sneezed at, it is an All Apple(Apple bought P.A. Simiconductor) design, and the P.A. simiconductor Boffins have a great CPU design pedigree(P.A. Simiconductior was founded by Daniel W. Dobberpuhl (BS EE 1967 University of Illinois, Urbana-Champaign), who was previously the lead designer for the DEC Alpha 21064 and StrongARM processors.) Apple went on a brain power/IP buying spree a few years back, and that Apple A7(runs the ARMv8 ISA) is a wide order superscalar design that can execute twice as many IPCs as the ARM Holdings ARMv8 refrence designs. The Apple A7 has the execution resources of an Intel Core i series CPU (see Anand’s article). The A7, and more so its replacement(A8) could probably do fine running the full OSX operating system. Tablet + Full Linux = better tool than Windows at a much better price, with much less bloat! Never underestimate Apple’s ability to purchase the best brain power and IP that money can buy!
The reg article say ARM is
The reg article say ARM is more efficient, Intel’s binary translation needs more work for Android OS.
I would rather have fully compiled applications running under a Full Linux distro closer to the metal, without a Android VM, Java VM, or what ever VM that requires translation on the fly. Full Linux Tablets NOW!
Note: OSs running under Hypervisor VMs with hardware support are a different story.