Intel's Medfield & Atom Z2460 Arrive for Smartphones: It's Finally Here
by Anand Lal Shimpi on January 10, 2012 8:00 PM ESTARM Compatibility: Binary Translation
Similar to Apple's move from PowerPC to x86, Intel finds itself in a difficult position with bringing Atom to Android. The OS isn't an issue as it has already been ported to x86 and all further releases will be available in both ARM and x86 flavors. The bigger problem is application compatibility.
There's already support for targeting both ARM and x86 architectures in the Android NDK so anything developed going forward should be ok so long as the developer is aware of x86.
Obviously the first party apps already work on x86, but what about those in the Market?
By default all Android apps run in a VM and are thus processor architecture agnostic. As long as the apps are calling Android libraries that aren't native ARM there, once again, shouldn't be a problem. Where Intel will have a problem is with apps that do call native libraries or apps that are ARM native (e.g. virtually anything CPU intensive like a 3D game).
Intel believes that roughly 75% of all Android apps in the Market don't feature any native ARM code. The remaining 25% are the issue. The presumption is that eventually this will be a non-issue (described above), but what do users of the first x86 Android phones do? Two words: binary translation.
Intel isn't disclosing much about the solution, but by intercepting ARM binaries and translating ARM code to x86 code on the fly during execution Intel is hoping to achieve ~90% app compatibility at launch. Binary translation is typically noticeably slower than running native code, although Intel is unsurprisingly optimistic about the experience on Android. I'm still very skeptical about the overall experience but we'll have to wait and see for ourselves.
Facebook
Twitter
RSS
164 Comments
View All Comments
french toast - Wednesday, January 18, 2012 - link
I agree with what you are saying, Intel is not competitive in the smartphone space...yet.. but they sure as hell will be within 18 months, this was just about getting a foot in the door..which lets be honest they tried before with moorestown..they even said similar things too, manufacturer tie ups?..remember LG!?But i get the feeling that had this been released mid last year it would have been competitive, but when released this year it will be old news.
I wouldn't take these Intel marketed benchmarks provided by anand too literally, they aren't better than current designs, but with silvermont followed by that steam train like 'tic tock' strategy they will have something to put the wind up ARM shareholders...
Hector2 - Wednesday, January 11, 2012 - link
I think everyone expected Medfield to perform well but the low power is surprising. But not you, eh ? One of those "glass is half empty" kind of guys are you ? Next up for Intel is the next gen 22nm that not only is faster & smaller than 32nm Medfield but has even lower active power and a 10X-20X standby power improvement due to having FinFET transistors. 22nm hits shelves in 2nd quarter for PCs but doesn't get into SoCs until 2013.Exophase - Tuesday, January 10, 2012 - link
Look at the data for the two tests you ran (that aligns perfectly with the only two tests Intel wants to report on, I might add!) - you see that the Galaxy Nexus does drastically better than the Galaxy SII despite having a very similar CPU arrangement. That should be a massive red flag that this test is right now more about software maturity than uarch, yet you use it to draw sweeping conclusions about uarch.These tests are about javascript. Javascript performance, while important, hardly dominates software usage on mobile platforms, nor is it representative of other programs. For one thing, it's JITed code and browser developers have spent a lot more time optimizing for x86 than ARM, while other platforms (GCC, Dalvik) are less slanted. For another thing, Javascript is double-precision float oriented, which isn't even remotely a standard nor useful programming paradigm for everything else that runs on phones.
All I can say is that you need to do some real benchmarks before you make the conclusions you have, and not just parrot the highly skewed selection Intel has given. That is, if you don't want to come off as Intel sponsored.
chuckula - Tuesday, January 10, 2012 - link
Uh... Android (which is what Intel is running) has been optimized for ARM all the way back to version 1.0. To come out now and complain that x86 is getting "unfair" software optimization advantages in its very first release before there has been much opportunity at all to do *any* real optimizations is really stretching things.If ARM wants more optimizations, it can contribute source code updates to GCC (it's open source after all).
Exophase - Tuesday, January 10, 2012 - link
Maybe you don't understand my post. These tests are JAVASCRIPT BENCHMARKS. Android optimization barely plays into it: what we're going to be looking at is Chrome optimization. You know what also doesn't play into it? GCC. The Javascript VM in the browser performs its own compilation, and JITs especially have really long development paths. I guess you missed what I said about the comparison of two different Android platforms, which shows that this is clearly an area where ARM performance is highly in flux and therefore immature and not representative.Regardless of whether or not you understand why this isn't a good test, you should at least understand that running only two benchmarks - two benchmarks that fall under the same category, no less - is a really pitiful way to draw conclusions about uarch. If anyone tried to pull this with an Intel or AMD desktop CPU they'd be immolated.
chuckula - Tuesday, January 10, 2012 - link
You want a wide range of benchmarks between a dual-core Cortex A9 and (older than Medfield) single core Atoms? Go here: http://www.phoronix.com/scan.php?page=article&...The brand-new Omap chip manages to win one real benchmark (C-ray) by 10%, a couple of synthetic cache benchmarks, and loses everything else to single-core Atoms that are actually slower than Medfield.
The benchmarks that Anandtech posted are *extremely* representative of what most people are doing on their phones most of the time. If you want performance numbers for "pure" applications, look at the Phoronix article.
The Dalvik JVM from Google has been optimized to run on ARM from day one. When I mentioned GCC, I was talking about the compiler used to COMPILE the Dalvik JVM (you do know the JVM isn't written in Java, right?). Dalvik is NOT the same JVM that you get from Sun/Oracle that (might) be more optimized for x86 than for ARM. In fact, Dalvik is a register-based VM while J2SE is a stack based VM, and Oracle has sued Google over it since Google lifted the Java interfaces but ditched the rest of the VM. Dalvik was only at beta-level operability with x86 during Honeycomb, and ICS is the first version to really work 100% with x86, but there's no rule saying that there couldn't be more optimizations for x86 based systems.
ARM has had *plenty* of time to work with GCC, Google, and anyone else who is needed to get optimizations introduced into Android. If it takes Intel entering the market to finally spur ARM into action, then I say it's about time this market got some real competition.
mczak - Tuesday, January 10, 2012 - link
I'm not convinced actually those older atoms shown in the phoronix article are really slower than Medfield. I don't think IPC of Medfield is really any higher, and even if it is (slightly) Medfield can only turbo up to 1.6Ghz (so might not run all the time at that frequency potentially) whereas those other atoms all run at 1.6Ghz. Memory bandwidth could also be potentially higher there. Not that it would change things much.Exophase - Tuesday, January 10, 2012 - link
It might have more memory bandwidth than an N270 IF paired with faster than 533MHz DDR2/3.. which I doubt you'll see in a phone. So I expect it to be pretty similar to the Z530's, all told.Clock for clock Medfield's CPU core sounds like it's a little faster due to some tweaks, but it all looks very minor. I'd be surprised if it improved anything by more than a few percent at most.
Exophase - Tuesday, January 10, 2012 - link
Right, now compare those numbers with this:http://openbenchmarking.org/result/1201051-AR-1112...
And this:
http://www.phoronix.com/scan.php?page=article&...
And the only sane conclusion is that Pandaboard ES is or the testing performed on it is critically broken. Now rethink your post.
Try your post again with those things in mind. And don't make me repeat myself any further, Javascript doesn't run on Dalvik, it runs on a Javascript VM. Do you seriously not understand this simple concept? Do you not understand how a purely web based language is not representative of - oh I don't know - apps that are running Java or C/C++ code?
french toast - Wednesday, January 11, 2012 - link
I have to say i am shocked to see those numbers, so much so i do wander about the validity of them as exophase has pointed out, especially since that 'fake' DX11 ivy bridge demo.Regarding the benchmarks, they are single thread right? so in actual fact you are comparing a 1.2ghz cortexa9 v 1.66ghz atom on different software and different process? i suspect that all things being equal the number would be very similar.
I take from the pandaboard tests exactly the same thing, that all clock speeds being equal that clock for clock atom is on par with cortex a9.
BUT that doesnt tell the whole story does it?..multi threaded apps including multiple tabbed web browsing..how would the atom fair against a duel core a9 clocked at 1.66ghz?
Its the power consumtion estimates that are the real suprise here..really? im under the impression that multicore SOCs spread the load across multiple cores to reduce power, and that arm had the power consumption 'in the bag' due to the complexity of x86 cisc v ARM risk.
The die area is also rather shocking, i thought it would be substantially bigger than that.
Whilst these numbers will give ARM vendors food for thought, lets not get ahead of our selfs just yet, Medfield is comparable to tegra 2 class designs(all things equal)
Krait, Cortex A-15 designs will be apon us by the time this launches..again on 28nm and 32nm designs...that should completely smoke this into oblivion.
The real worrying thing is not about this year its next year, if they can match a exynos 4210 when many thought they didnt have a chance..then silvermont on 22nm FINfet will be scary for arm, since they have already convinced Motorolla to sign a multi year deal and they have billions and billions to chuck around..i would be worried if i was an investor with ARM.