Slashdot Mirror
New Analysis Casts Doubt On Intel's Smartphone Performance vs. ARM Devices
MojoKid writes "A few weeks ago, the analyst company ABI Research published a report claiming that Intel's new CloverTrail+ platform (dual-core Medfield) for smartphones was significantly faster and more power efficient than anything ARM's various partners were shipping. If you follow the smartphone market, that was a very surprising claim. Medfield was a decent midrange platform when it launched in 2012, but Intel made it clear that its goal for Medfield was to compete with other platforms in its division — not seize the performance crown outright. Further investigation by other analysts has blown serious holes in the ABI Research report. Not only does it focus on a single, highly questionable benchmark (AnTuTu), the x86 version of that benchmark is running different code than the ARM flavors. Furthermore, the recently released Version 3.3 of the test is much faster on Intel hardware than on any of the other platforms. But even with those caveats in place, the ABI Research report is bad science. Single-source performance comparisons almost inevitably are."
The arm fanboys
Android apps (if they're made correctly,) run on Dalvik, which is platform indapendent. The virtual machine is compiled for ARM & x86 both, and it in turn runs the android apps.
Android supports compiling for x86.
So not all of those are ARM exclusive.
Well, most android apps aren't compiled at all. Java JIT remember?
Not if you use the NDK, which most games and video applications will use for performance reasons.
You can of course compile for both.
Intel cooking the books on a benchmark? Never happen.
I design chips and work for intel.
Clover Trail is significantly more power efficient than Medfield because it has a lot more power control stuff in it, so more of it is turned off most of the time. This is not a big secret as far as I know.
The rest of the phone consumes power too, particularly the screen. So YMMV.
interesting though that you included WP apps in the list, since surely there are far more x86 apps that could be opened up to that platform.
Apple too might benefit from a shared architecture between the desktop and phone, though honestly if they said tomorrow "We're switching to SPARC processors, everyone re-write your apps" Everyone would giddily proclaim the dawn of the new sparc era and get to work. (Oh, how I wish. It's my 2nd favorite processor behind the 680x0)
Every iOS app was compiled for x86 also (iOS simulator), but it doesn't mean any games ship with that binary.
Just because you can easily cross compile does not mean a platform will not have a huge hurdle out of the gate just getting someone to re-compile a build.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
ARM has been focusing on mobile platform architecture for much longer than intel, its like Honda trying to make a truck, sure they did do it but its nothing like a company making nothing but trucks from the get-go. Intel needs to stay right where they are king and keep that crown and stop trying to follow rabbit holes thinking they might find money where ARM is the clear leader down in those places.
News at 11.
I don't think there's any chipmaker (CPU, GPU or otherwise) who hasn't been caught doing it. Not that that makes it right, of course.
For the quick readers, note that this is about Clover Trail, not to be confused with the recently announced Bay Trail. Though it does cast doubts on Intel's claims about the latter's performance...
Use something other than a well engineered and architected Microsoft compiler
I know of the NDK, which is why I stated "if they're made correctly." Google put out documentation very clearly stating the disadvantages of doing NDK, and plenty of creators ignored the best practice and did it anyway; which is the WRONG way to do it.
Apple too might benefit from a shared architecture between the desktop and phone
It'd have to be a hell of a lot more than a "might benefit" for them to do it. It'd have to be the inability of one of the platforms to support future requirements in their existing niche. Which is a very far distant prospect in each case.
App stores make this less of an issue. If Apple wants to switch the iDevices to x86, they'll tell developers that they must have an x86 build posted by such-and-such date, or their app will be dropped from the store.
If that is the only way to get the performance you need, it is the right way.
Using the NDK is not wrong, it is just an option. The play store should really demand x86 and ARM executable for all apps.
2 billion?
The last Atom/Android phone I read about had an ARM emulator for running NDK apps. Performance suffers, but it's better than not running at all (particularly since Atom is more powerful than the common Cortex-A9 cores, so it has some performance to burn).
Benchmarks and polls have to be funded so the people behind them can feed their children.
That's why results ofthen don't match realiy.
So how do you propose writing code which is portable between Android and iPhone?
I'm REALLY curious about this one...
Single-source performance comparisons almost inevitably are, yet this point is being made by none other than a single person. I love the irony.
The price is always right if someone else is paying.
Most android apps are compiled for dalvik and don't care what processor is running dalvik.
2 billion?
For small values of 2 billion.
Its. As in "its goal", not "it's" as in "It's...Monty Python's Flying Circus!"
If you write your code in C, you can port it relatively easy to iPhone, Android, WP8, and Blackberry (depending how much UI code you have). If you write it in Java, avoiding the NDK, you have to do two-four times as much work to port it.
Which would you rather do, use the NDK and recompile, or write once for each platform? "The right way" isn't always a single choice, it's usually a compromise.....
If Intel processors become popular in Android phones, Google will probably introduce a multiple-architecture executable format, much like iPhone does with FAT and MACH (currently around 70% of apps for the iPhone have two architectures, one for ARM7 and one for ARM7s).
"First they came for the slanderers and i said nothing."
Every technology has advantages and disadvantages. NDK's no exception. Downside: has to be compiled on a per-architecture basis. Upside: Improved performance, and the possibility of a lot of your codebase compiling on other, non-Android devices.
What's really hilarious is that this supposedly "rigged" benchmark got almost zero press (never posted on Slashdot or mentioned on major tech websites) when it first came out. Now the ARM religion has to wage a jihad on anybody who claims that it is physically possible to use silicon that doesn't include royalty payments to the Church of ARM to run your smartphone.
Using my own ARM-based smartphone and the Dexplorer app, I looked at Antutu and other common Android benchmarks. One interesting thing that stood out was that Antutu uses the NDK (i.e. there are C-compiled libraries for both ARM + x86 ABIs). The other benchmarks like quadrant and Linpack were pure java based. Basically what I'm seeing is that the Clovertrail+ x86 hardware absolutely is in the same ballpark as the snapdragon 600 for performance, but that the ARM vendors and Android developers have been optimizing Dalvik for the ARM architecture since 2009 while little has been done for x86. Once a real compiler like GCC gets to generate C-code for the x86 Atoms though (and also for the ARM parts BTW, it's a level playing field), then we see that Clovertrail+ puts up decent competition for modern ARM chips in the same power envelope.
As for the usual: "Intel cheats using compilers!" whine, please take a big dose of vitamin STFU. I've been bored to death for over a decade by the drone of the ARM jihadists who claim that their architecture is so magical that you can literally knock back a fifth of Tequila and vomit up a perfectly optimized web browser before breakfast. If ARM is truly so beautiful and if the engineers at ARM are truly such geniuses, then it should be trivial for them to implement compilers that blow away x86.
App stores make this less of an issue. If Apple wants to switch the iDevices to x86, they'll tell developers that they must have an x86 build posted by such-and-such date.
Apple DOES NOT do that for older apps. It will often place restrictions on app updates or new app submissions (like must include iPhone5 screen shots) but they don't ever force older apps to do any kind of update - nor should they.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Or right forgot, it was just a marketing slogan.
Bytecode, remember?
If you can't buy one of these, who cares?
Phonegap
Peter predicted that you would "deliberately forget" creation 2000 years ago...
And why not MIPS? It's a pretty popular CPU in China, and has certainly been used in Android based phones and tablets.
PowerPC is a pretty good-performing mobile CPU, too. And I'm sure SuperH CPUs still have their adherents somewhere.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Some guy on the Anandtech forums analysed the AnTuTu code and found that it indeed had been tweeked to favor x86 processors:
http://forums.anandtech.com/showthread.php?t=2330027
No new analysis has occurred. No additional benchmarks have been run, no new power consumption measurements have been taken. A previous analysis has been, if not discredited, at least had its limitations explicitly described.
Actually, no: a large plurality of Android apps are coded to Dalvik, which is basically (pun intended) java bytecode. Very few Android apps use the alternative (Native something something), which allows ASM or whatever, and then only for small snippets. That's why Android apps run indifferently on ARM, x86, and MIPS... various versions of those actually.
Optimization is another matter, but that's mostly fro GPU stuff.
The Cloud - because you don't care if your apps and data are up in the air.
Personally I think the best case would be the code is uploaded not any binaries. That way the store can make binaries as needed for new architectures.
lies damn lies benchmarks manufactures' benchmarks
Not if you use the NDK, which most games and video applications will use for performance reasons.
You can of course compile for both.
extend the if done correctly to enabling x86 compiling for the native parts.
I really doubt that there's that many apps there that have hand crafted assembly in them...
though this myth that it doesn't have x86 support might have been pushed forward by the action from intel of writing an arm translator for those apps that haven't been ndk compiled for x86.
world was created 5 seconds before this post as it is.
"This is what we call breaking the benchmark. Where the compiler applies some logic that makes the benchmark much faster by doing a set of operations that the benchmark identifies as correct (if it even checks) but are not performing the intended function of the benchmark."
Better instruction set in x86 and better compiler. it might not have been intentional. What happens is that when compiled for x86 it produces faster code for what the benchmark actually does. and that it uses vastly less instructions should come as no surprise to anyone!
The overall state of the tooling (gcc+arm v. icc+x86) is highly relevant. Intel invests a lot in things like icc in order to make software naturally take best advantage of their design. To dismiss that value would be unfair as well.
In this case, there was a sign tht some recent gcc optimizations were not used, but a follow up said when those were applied, the results in this case didn't vary as much as perhaps hoped.
Every iOS app was compiled for x86 also (iOS simulator), but it doesn't mean any games ship with that binary.
Just because you can easily cross compile does not mean a platform will not have a huge hurdle out of the gate just getting someone to re-compile a build.
if you enable the x86 portion then the app ships with both x86 and arm ndk compiled binary parts... and mips too.
all major apps would have that shit working instantly if they got even 10% of the android share.. or sooner, if it makes a good showcase.
world was created 5 seconds before this post as it is.
I always thought MIPS would be a better choice than ARM for low power servers... MIPS already has a 64bit variant which is well tried and tested.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Intel and Microsoft soak all the technical websites with hundreds of millions of dollars every year, buying favourable coverage for their products.
For instance, Anandtech (one of the very worst for taking Intel pay-offs) recently ran a 'gaming' battery-life benchmark that consisted of allowing a free-running GPU benchmark program that works by timing how long it takes to complete a certain number of rendered frames of pseudo game data. Anandtech CLAIMED that their benchmark measured battery life in gaming situations. Of course, the weaker the GPU (and Intel's GPUs tend to be very weak indeed) the less work the GPU does per hour, and thus the less power the GPU benchmark takes.
The bent Anandtech benchmark showed Intel as a big winner, of course. But then again, when AMD launched its first combined CPU+GPU chips in laptops, Anandtech refused to publish the graph showing the gaming life of the device, because that one benchmark doubled Intel's score. However, Anandtech did include 20 other graphs in their review which all showed LESSER performance than Intel.
Most people only read the headlines or skip to the conclusions of the review. Often the body of text is a lot more honest than the weasel words at the top and bottom of the review, allowing the reviewer to ease their conscience somewhat.
Intel chips are a LOT worse than most of you realise, being only for the most part a little better than AMD if cost is excluded as a factor. Factor cost in, and AMD often wins. (To be fair, factor power use in, and AMD tends to comprehensively lose on the mains powered high-end platforms).
Against ARM, and Intel is a total joke. Even if Intel were equal at a tech level (and it is most certainly not- Intel's disastrous dalliance with FinFET is leading them to be crucified by ARM devices using FD-SOI), the Intel Tax will always make Intel an unacceptable platform.
What is the Intel Tax?
1) Massive increase in die area for units that translate the rotten x86 ISA to the internal RISC one.
2) Massive power usage by that translation block
3) Massive IP costs for everything that makes x86 'special' (special in the short-bus sense)
4) Massive coding inefficiency overhead for having to control the true internal RISC ISA with code written to the x86 ISA (usually emitted by a compiler, of course)
ARM misses all of this legacy nonsense. ARM, since version 2 (version one was used in a mains powered desktop computer) has been designed from the ground up for low power use.
Intel has one last, incredibly dishonest, trick up its sleeve- and you are seeing sites like Anandtech exploit this lie. Intel mobile chips are thermally throttled, and this means they can burn desktop like power amounts for very short periods. If a benchmark can be completed in this period (once), the throttling is avoided, the chip can auto-clock to obscene speeds, and the benchmark score will seem amazing.
So Anand at Anandtech is encouraging the use of mobile benchmarks of the shortest possible duration to inflate Intel's mobile scores. Now a game, for instance, needs to be continuously doing work. A game will suffer maximum continuous thermal throttling, and will show the real performance of the system. None of Intel's power saving tricks help them with real apps/games.
In fairness to Anandtech, they run a fascinating comparison of gaming performance across tablets AND older PC system, showing the best ARM tablets as having the gaming performance of high-end PCs from not all that long ago (but today's gaming PCs are vastly more powerful).
Anyway, FD-SOI is ringing the death knell for Intel. Intel bet the farm on FinFET and that bet has not paid off. All Intel can now do is pay millions for good PR, and prey their 2015 or later parts with Nvidia graphics will turn things around. In the mean time, Intel is going to make ZERO worthwhile progress in the mobile space.
I hope this doesn't surprise anyone, but they're running different code. They're also running different instruction sets. And they likely have different memory controllers and caches sizes. I think we can say that Intel is pretty darn good an running AnTuTu, but that's all that graph says.
Java Android apks run just fine on Medfield.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
This was a great article , if you want to read some other great article come at http://easycode.me I read the history of x86 and I really love this processors...
1) Massive increase in die area for units that translate the rotten x86 ISA to the internal RISC one.
2) Massive power usage by that translation block
3) Massive IP costs for everything that makes x86 'special' (special in the short-bus sense)
4) Massive coding inefficiency overhead for having to control the true internal RISC ISA with code written to the x86 ISA (usually emitted by a compiler, of course)
5) Massive cost of supporting multiple overlapping compute models such as x87, mmx, sse, sse2, blah, blah, blah...
6) Massive cost to support stupid number of obsolete and legacy instructions that nobody care about but still need to perform well to avoid performance regressions on old binaries
When all you have is a hammer, every problem starts to look like a thumb.
Clovertrail+ is old tech. It's just a rehash of the old atom line. It was never going to be anything more than a stepping stone, or something to flesh out Intel's product line. It's nothing to be excited about.
Baytrail, with silvermont cores, however is going murder Arm in it's crib if it's even half as good as early reports claim. Intel's latest 22nm fabrication tech. Based off of latest gen haswel "core" cpu tech (So real out of order execution). Real intel graphics, not an awful powerVR IP core (Important if you're going to run windows). Completely designed from the ground up for power efficiency. (All pre-haswell intel cpus have bolt-on, after the fact power managment tech)
Baytrail is supposed to enable sub-200 dollar windows 8 tablets. Not windows RT. Full windows 8.
The silvermont cores will be going in to phone oriented SoCs that should also be impressive.
One of the problems I see with arm SoCs meant for anything other than smartphones is that they're a disorganized mess. Each chip is damn near an architecture of it's own. That's why there is no such thing as a universal android system image. You have to custom compile for EACH DEVICE. For all the problems with x86/x64/PC arch, it sure is easy to throw your windows or linux distro CD in and install a working OS.