Intel's Medfield & Atom Z2460 Arrive for Smartphones: It's Finally Here
by Anand Lal Shimpi on January 10, 2012 8:00 PM ESTIt's here. Intel's first smartphone SoC that you'll actually be able to buy in a device before the end of the year. The platform is called Medfield and Paul Otellini just announced its first device partners.
Medfield starts out as a bonafide mobile SoC. Whereas Moorestown was a "two-chip" solution, Medfield is just one - the Penwell SoC:
The SoC is only available in a PoP (Package on Package) configuration measuring 12mm x 12mm. Intel wouldn't give out a die size but it did show me a Penwell sample without the stacked DRAM:
Since I know the measurements of the package I could estimate the dimensions of the silicon itself. My math worked out to be around 62mm^2. That's larger than a Tegra 2-class SoC, but smaller than Tegra 3 or Apple's A5. The diagram of its high level architecture above helps explain why.
There's only a single version of Medfield being announced today: the Intel Atom Z2460. The Z2460 features a single Atom core with a 512KB L2 cache, a PowerVR SGX 540 GPU and a dual-channel LPDDR2 memory interface. In a world where talking about four Cortex A9s and PowerVR SGX 544MP2s isn't uncommon, Medfield starts out almost sounding a bit...tame. But then you see its performance:
Although running what appears to be a stock Gingerbread browser, Intel's Medfield reference platform posts SunSpider performance better than any other smartphone we've tested - including the Galaxy Nexus running Ice Cream Sandwich. Intel promises that Medfield's performance will scale on ICS as well - the gap should be maintained. We've seen high results from reference designs in the past, but the Medfield platform is a little different as you'll soon see - it's a complete smartphone design that should be representative of handsets that hit the market later this year.
Medfield isn't a one trick pony either, performance is similarly dominating under BrowserMark:
These are tablet-like scores. Here the Galaxy Nexus running ICS comes close, but once again Intel expects that on the same OS Medfield should be faster than any of the currently available SoCs.
I asked Intel where its SunSpider and BrowserMark performance advantages came from, especially considering we've typically only seen huge gains with new browsers and not new SoCs. Their response pointed to a bunch of factors, but one stand out issue was the A9 has a great execution core but seems to be more limited on the memory interface. Atom can support far more outstanding misses in L2 than the Cortex A9, which chokes bandwidth to the processor for anything not already in the L2 cache. This may be one of the reasons why we've never been able to get really high bandwidth numbers out of A9 based SoCs. It's probably safe to assume that things will be different with the Cortex A15, but for now it's little things like this that give Medfield a performance advantage.
GPU performance is understandably not as impressive. We couldn't get offscreen numbers of GLBenchmark 2.1 but we did get results at the device's native resolution (1024 x 600):
3D performance is better than the OMAP 4460 due to Medfield's 400MHz GPU clock compared to ~300MHz in most OMAP4 devices.
Performance without power considerations is meaningless, especially in the smartphone world. Luckily for Intel, Medfield seems very competitive there as well. Intel provided some power and performance data for Medfield based on its reference platform. I still haven't been able to verify any of this for myself, but I was able to see some power tests run in person on the reference platform and competitive devices.
The Intel provided values are pretty astonishing . Sub 20mW idle, sub 750mW during a call on 3G and although not pictured here, Intel's internal data suggests ~1W power consumption while browsing the web compared to ~1.3W on the iPhone 4S and Galaxy S 2. I've done my own measurements on 4S web browsing and came up with a very similar value.
| Intel Measured Smartphone Power Consumption (Identical Display Brightness) | ||||||
| Standby (3G) | Talk (3G) | Browsing (3G) | Video Playback 720p | |||
| Apple iPhone 4S | ~38mW | ~800mW | ~1.3W | ~500mW | ||
| Intel Medfield Reference | ~18mW | ~700mW | ~1.0W | ~850mW | ||
| Samsung Galaxy S II | ~19mW | ~675mW | ~1.2W | ~650mW | ||
The performance and power data both look great for Medfield. You would think that this data, assuming there's nothing fundamentally wrong, would be enough to convince a handset maker to actually give Intel a shot. You'd be right.
In addition to disclosing Medfield performance data, Intel is also announcing partnerships with both Motorola and Lenovo. The former is a broad, multi-year agreement stating that Motorola plans on creating many devices based on Intel silicon - the first of which will be a smartphone due out before the end of the year. Tablets will follow at some point as well.
Lenovo on the other hand will actually be taking and tweaking Intel's own Medfield reference platform, and releasing it in China in Q2.
All of this is exactly what Intel needed: a start.
Facebook
Twitter
RSS
164 Comments
View All Comments
janderk - Wednesday, January 11, 2012 - link
The numbers are still impressive, but there isn't such a thing as a stock Gingerbread browser performance.The Intel phone currently runs Android 2.3.7 in which browser performance is on par with Honeycomb/ICS. You can't compare those numbers with a S2 or Sensation running old Honeycomb versions. If you do, you are comparing Android versions more than hardware.
Google seems to have backported some browser code pieces to Gingerbread. A galaxy S2 on 2.3.6 with a stock ROM/browser scores around 90.000 in the Browsermark and around 2200 in the Spidermark. Ask Brian. He double checked and got even better numbers than I got.
Lucian Armasu - Wednesday, January 11, 2012 - link
That's a very good point. I wouldn't put it past Intel to "hype up" their marketing a little too much. I've been watching them very closely regarding this lately, and a lot of what they are saying is simply BS.Let's wait until we actually have the product in the market before we evangelize their yet to be seen chips.
Wilco1 - Wednesday, January 11, 2012 - link
While I like your article, you can't really conclude anything about micro archictures based on 2 micro benchmarks which have likely been highly tuned by Intel. Also note the Atom runs at 1.6GHz while the Nexus runs at 1.2GHz, so much of the performance difference is simply due to frequency.For a recent comparison between Cortex-A9 and Atom, check out these:
http://www.phoronix.com/scan.php?page=article&...
http://openbenchmarking.org/result/1201051-AR-1112...
In these 1.0 and 1.2GHz Cortex-A9 SoCs completely obliterates 1.6GHz netbook Atoms in performance on mostly single-threaded benchmarks. So in terms of micro architecture comparison, your article is dead wrong. When compared using same compiler and OS, the A9 beats Atom at a much lower frequency due to having higher IPC as a result of out-of-order execution. Note how it scores much higher on most memory benchmarks.
milli - Wednesday, January 11, 2012 - link
Actually the Z2460 runs at 1.3Ghz but can turbo to 1.6Ghz.Something might be up with the PandaBoard ES. Phoronix also has a Tegra 2 based review and that one also scores better on some tests than the PB-ES (just like the Exynos). The problem is that the scores are not really comparable because all three (PB-ES, T2, Exynos) use different compilers and kernels. Only the PB-ES uses the same compiler (and probably parameters) as the x86 systems. So you'll need to wait for real Medfield reviews when the time comes (or for Phoronix to do a better comparison). Especially the Exynos results need to be taken with a grain of salt since they used a total of three compilers there.
It's known that Atom's single threaded performance is bad. It has HyperThreading to cover that up. Since Android's JavaScript engine is multi-threaded, Atom performs well.
Wilco1 - Wednesday, January 11, 2012 - link
True, but you can bet Intel ensured the benchmarks were run at 1.6GHz, even if that wouldn't be feasible in a real phone due to cooling. So we have to wait for an actual phone with a standard Android version for the real comparison.There are indeed issues with the Panda board, the Ubuntu version used isn't compatible with the OMAP4460 so it isn't setup correctly. There are also compiler option issues and use of a slow flash card which reduces the scores. In terms of compilers used, GCC 4.5 or 4.6 doesn't make a major difference, so these benchmarks give a reasonable indication how Cortex-A9 would do vs Medfield.
If Android JavaScript is multithreaded, you'd expect a dual core A9 to do much better than Atom as you get a 100% speedup from the second core, not just 30% from hyperthreading. I suppose we'll see when the Intel improvements are added to the mainstream Android version.
Wilco1 - Wednesday, January 11, 2012 - link
True, but you can bet Intel ensured the benchmarks were run at 1.6GHz, even if that wouldn't be feasible in a real phone due to cooling. So we have to wait for an actual phone with a standard Android version for the real comparison.There are indeed issues with the Panda board, the Ubuntu version used isn't compatible with the OMAP4460 so it isn't setup correctly. There are also compiler option issues and use of a slow flash card which reduces the scores. In terms of compilers used, GCC 4.5 or 4.6 doesn't make a major difference, so these benchmarks give a reasonable indication how Cortex-A9 would do vs Medfield.
If Android JavaScript is multithreaded, you'd expect a dual core A9 to do much better than Atom as you get a 100% speedup from the second core, not just 30% from hyperthreading. I suppose we'll see when the Intel improvements are added to the mainstream Android version.
BSMonitor - Wednesday, January 11, 2012 - link
"If Android JavaScript is multithreaded, you'd expect a dual core A9 to do much better than Atom as you get a 100% speedup from the second core, not just 30% from hyperthreading. I suppose we'll see when the Intel improvements are added to the mainstream Android version. "No, you wouldn't get 100% speed bump because there are many more factors besides CPU resources that ultimately affect performance.
You are clearly a noob fanboy on a rant.
Wilco1 - Wednesday, January 11, 2012 - link
How much speedup you get obviously depends on lots of factors. However the fact remains that 2 cores have much more raw performance than 1 core with hyperthreading, so if JS is really multithreaded then the advantage would be to ARM, not Atom.virtual void - Thursday, January 12, 2012 - link
You have to keep, at least, two things in mind here1. The efficiency on the second HT in Atom is much higher than the 20-30% you see on Sandy Bridge. On Atom, 50-60% is probably a more accurate number based on a number of test I've done myself. And this is not because Atom in anyway is better than Sandy Bridge, it is quite the opposite. The in-order design and simple executions units in Atom will cause a lot more pipeline stalls which means that the other thread will get access to all the power (or lack of power) in the CPU.
2. You are that two physical cores has more raw power than two HT on the same core. But when you run a single program on two treads and work on the same data, HT has a huge benefit in that the two program threads will communicate via the L1 cache (shared between the HT) while two threads running on different physical cores will communicate via the L2 cache. The L1 cache has a much lower latency and much higher bandwidth compared to the L2 cache.
So HT can be very efficient in accelerating things where two threads are working on the same data-set. But two physical cores is probably always better when you have two threads running different programs or at least working on a data-set that is completely thread local.
Wilco1 - Thursday, January 12, 2012 - link
You're right if 2 threads belong to the same process and communicate a lot then HT has lower overheads, but the downside is that you quickly start trashing the small L1 caches. HT works better on Atom indeed, but 50-60% on average sounds a bit high, especially since Atom stalls on cachemisses.