Near 50% performance of a high end ARM processor using Atom would be quite the impressive trick.
That's not what the < 50% figure means. The description I gave was probably pretty confusing, let me try again..
When someone says that an emulator gets X% of native it means that you take:
1) Binary A is a program compiled for the native instruction set.
2) Binary B is a program compiled for the instruction set you're going to be emulating, using the same compiler (of course even the same compiler might produce better, sometimes much better code for a different ISA)
And then compare how binary A runs when executed directly vs how binary B runs when executed in the emulator.
It's not a comparison between the emulation and how it runs on something that natively executes what you're emulating. That only holds if the two chips have the exact same performance which is never going to be true.
On that point, I believe Atom and Cortex-A9 have similar perf/MHz with A9 being slightly higher, but even Medfield can turbo well past the clocks we see in A9s out (and has quite good power consumption at these high clocks, props to Intel for this). A lot of people will disagree. Some are even saying Krait and Atom have clock for clock parity. A lot of these conclusions are drawn from Javascript benchmarks; other stuff tends to paint a different picture. I've argued a lot about why I don't like JS benches and why I think JS engines are still generating better x86 code than ARM, even on this forum.. I won't bother repeating it, everyone is free to look at what data they can and draw their own conclusions. Hopefully no one thinks that Atom is ahead of Cortex-A15 in perf/MHz (and the MHz numbers are more similar with what we have so far), at least in single threaded stuff. And that's the current high end for ARM, with Swift being a near runner up. So doing nearly 50% native emulating ARM is not going to give you 50% highest end ARM performance. And honestly I think the real world numbers will be closer to 40% if not worse - the numbers for the non-hardware assist version were a little over 40%. But they're skewed over what you could get on Medfield by using x86-64, and they were systemically skewed because they got a huge benefit in one benchmark (mcf) because native used 64-bit pointers and emulated used 32-bit pointers.
Personally, I think ~40% or even 50% isn't good enough for anything performance critical. If if were we wouldn't be arguing about the finer points of CPU perf/W in mobile space.
On the other hand, I think the market interests are totally superficial anyway when you consider how much emphasis is placed on Javascript code which is throwing a huge amount of performance by virtue of the language. People are eager to pick over +/-20% perf/W in hardware (I am too, of course) but don't seem to care at all about code performing at 1/5th or worse what it could in a different language.
Intel17 said:
Fair enough. But it seems clear to me that the binary translation is simply a band-aid until Intel can get developers to re-compile their code. From the reviews of the Motorola Droid Razr i, the apps compatibility is quickly becoming a non-issue.
Pretty much, but you can't get everyone to convert. Unless Intel wants to write out a LOT of big checks. Until the market share is compelling some will even avoid it purely out of bias.
I'm curious, did these reviews test a lot of games? I've read two Medfield reviews that looked into app compatibility. One of them tested exactly one game and it ran fine. The other tested two games and one ran fine while the other ran poorly. Seems to me review sites barely care about testing games on phones. But games are among the more intensive software.
I'm not a normal market player so this might not matter, but I've written thousands of lines of (Cortex-A8/A0 optimized) NEON for mobile platforms. Until Intel becomes a much bigger player here there's no way I'm even entertaining the idea of writing thousands of lines of Atom-optimized SSSE3. Believe me, both tasks are awful.
Unfortunately for Intel, I suspect that said hand-optimized NEON is going to fare worse than average in their binary translation, this stuff doesn't map that well at all.
Facebook
Twitter