Final Words

Intel finally did it. After almost five years of talking about getting into mobile phone form factors, Intel went out and built a reference platform that proved what they've been saying was possible all along. Furthermore, Intel also finally landed a couple of partners who are willing to show their support by incorporating Medfield into their product portfolio. The releases are still a few months away at the earliest (possibly even longer for Motorola) but it's much better news than Intel has ever reported before in this space.

 


Medfield (left 1) vs. Moorestown (right 2)

The partnerships aren't out of pity either: Medfield is fast. I firmly believe had it been released a year ago it would have dominated the Android smartphone market from the very start. Even today it appears to deliver better CPU performance than anything on the market, despite only having a single core. GPU performance is still not as fast as what's in the A5 but it's competitive with much of the competition today, and I fully expect the dual-core version of Medfield to rectify this problem.

Based on the data Intel shared with us as well, the x86 power problem appears to be a myth - at least when it comes to Medfield. I'm still not fully convinced until we're able to test a Medfield based phone ourselves, but power efficiency at the chip level doesn't seem to be a problem.

Medfield and the Atom Z2460 are a solid starting point. Intel finally has a chip that they can deliver to the market and partners to carry it in. Intel also built a very impressive reference platform that could lead to some very interesting disruptions in the market.

While I'd like to say that Intel's Medfield team can now breathe a sigh of relief, their work is far from over - especially with more competitive ARM based SoCs showing up later this year. I'm really interested to see where this goes in the next 12 months...

ARM Compatibility: Binary Translation
POST A COMMENT

163 Comments

View All Comments

  • 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. Reply
  • 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.
    Reply
  • 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).
    Reply
  • 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.
    Reply
  • 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.
    Reply
  • 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. Reply
  • 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.
    Reply
  • 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?
    Reply
  • 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.
    Reply
  • Hector2 - Wednesday, January 11, 2012 - link

    So you doubt Anand's power measurements too ?

    As for the DX11 demo, Intel's VP showed very poor judgement running a video when they had trouble getting the demo out in time -- that's a major screw up, but Anand showed that the hardware actually works in spite of the screwed up demo.
    Reply

Log in

Don't have an account? Sign up now