The Apple iPad Review (2012)
by Vivek Gowri & Anand Lal Shimpi on March 28, 2012 3:14 PM ESTThe A5X SoC
The ridiculousness of the new iPad begins at its heart: the A5X SoC.
The A5X breaks Apple's longstanding tradition of debuting its next smartphone SoC in the iPad first. I say this with such certainty because the A5X is an absolute beast of an SoC. As it's implemented in the new iPad, the A5X under load consumes more power than an entire iPhone 4S.
In many ways in the A5X is a very conservative design, while in others it's absolutely pushing the limits of what had been previously done in a tablet. Similar to the A5 and A4 before it, the A5X is still built on Samsung's 45nm LP process. Speculation about a shift to 32nm or even a move TSMC was rampant this go around. I'll admit I even expected to see a move to 32nm for this chip, but Apple decided that 45nm was the way to go.
Why choose 45nm over smaller, cooler running options that are on the table today? Process maturity could be one reason. Samsung has yet to ship even its own SoC at 32nm, much less one for Apple. It's quite possible that Samsung's 32nm LP simply wasn't ready/mature enough for the sort of volumes Apple needed for an early 2012 iPad launch. The fact that there was no perceivable slip in the launch timeframe of the new iPad (roughly 12 months after its predecessor) does say something about how early 32nm readiness was communicated to Apple. Although speculation is quite rampant about Apple being upset enough with Samsung to want to leave for TSMC, the relationship on the foundry side appears to be good from a product delivery standpoint.
Another option would be that 32nm was ready but Apple simply opted against using it. Companies arrive at different conclusions as to how aggressive they need to be on the process technology side. For example, ATI/AMD was typically more aggressive on adopting new process technologies while NVIDIA preferred to make the transition once all of the kinks were worked out. It could be that Apple is taking a similar approach. Wafer costs generally go up at the start of a new process node, combine that with lower yields and strict design rules and it's not a guarantee that you'd actually save any money from moving to a new process technology—at least not easily or initially. The associated risk of something going wrong might have been one that Apple wasn't willing to accept.
| CPU Specification Comparison | ||||||||
| CPU | Manufacturing Process | Cores | Transistor Count | Die Size | ||||
| Apple A5X | 45nm | 2 | ? | 163mm2 | ||||
| Apple A5 | 45nm | 2 | ? | 122mm2 | ||||
| Intel Sandy Bridge 4C | 32nm | 4 | 995M | 216mm2 | ||||
| Intel Sandy Bridge 2C (GT1) | 32nm | 2 | 504M | 131mm2 | ||||
| Intel Sandy Bridge 2C (GT2) | 32nm | 2 | 624M | 149mm2 | ||||
| NVIDIA Tegra 3 | 40nm | 4+1 | ? | ~80mm2 | ||||
| NVIDIA Tegra 2 | 40nm | 2 | ? | 49mm2 | ||||
Whatever the reasoning, the outcome is significant: the A5X is approximately 2x the size of NVIDIA's Tegra 3, and even larger than a dual-core Sandy Bridge desktop CPU. Its floorplan is below:
Courtesy: Chipworks
From the perspective of the CPU, not much has changed with the A5X. Apple continues to use a pair of ARM Cortex A9 cores running at up to 1.0GHz, each with MPE/NEON support and a shared 1MB L2 cache. While it's technically possible for Apple to have ramped up CPU clocks in pursuit of higher performance (A9 designs have scaled up to 1.6GHz on 4x-nm processes), Apple has traditionally been very conservative on CPU clock frequency. Higher clocks require higher voltages (especially on the same process node), which result in an exponential increase in power consumption.
| ARM Cortex A9 Based SoC Comparison | ||||||
| Apple A5X | Apple A5 | TI OMAP 4 | NVIDIA Tegra 3 | |||
| Manufacturing Process | 45nm LP | 45nm LP | 45nm LP | 40nm LPG | ||
| Clock Speed | Up to 1GHz | Up to 1GHz | Up to 1GHz | Up to 1.5GHz | ||
| Core Count | 2 | 2 | 2 | 4+1 | ||
| L1 Cache Size | 32KB/32KB | 32KB/32KB | 32KB/32KB | 32KB/32KB | ||
| L2 Cache Size | 1MB | 1MB | 1MB | 1MB | ||
| Memory Interface to the CPU | Dual Channel LP-DDR2 | Dual Channel LP-DDR2 | Dual Channel LP-DDR2 | Single Channel LP-DDR2 | ||
| NEON Support | Yes | Yes | Yes | Yes | ||
With no change on the CPU side, CPU performance remains identical to the iPad 2. This means everything from web page loading to non-gaming app interactions are no faster than they were last year:
JavaScript performance remains unchanged, as you can see from both the BrowserMark and SunSpider results above. Despite the CPU clock disadvantage compared to the Tegra 3, Apple does have the advantage of an extremely efficient and optimized software stack in iOS. Safari just went through an update in improving its Javascript engine, which is why we see competitive performance here.
Geekbench has been updated with Android support, so we're able to do some cross platform comparisons here. Geekbench is a suite composed of completely synthetic, low-level tests—many of which can execute entirely out of the CPU's L1/L2 caches.
| Geekbench 2 | ||||||
| Apple iPad (3rd gen) | ASUS TF Prime | Apple iPad 2 | Motorola Xyboard 10.1 | |||
| Integer Score | 688 | 1231 | 684 | 883 | ||
| Blowfish ST | 13.2 MB/s | 23.3 MB/s | 13.2 MB/s | 17.6 MB/s | ||
| Blowfish MT | 26.3 MB/s | 60.4 MB/s | 26.0 MB/s | - | ||
| Text Compress ST | 1.52 MB/s | 1.58 MB/s | 1.51 MB/s | 1.63 MB/s | ||
| Text Compress MT | 2.85 MB/s | 3.30 MB/s | 2.83 MB/s | 2.93 MB/s | ||
| Text Decompress ST | 2.08 MB/s | 2.00 MB/s | 2.09 MB/s | 2.11MB/s | ||
| Text Decompress MT | 3.20 MB/s | 3.09 MB/s | 3.27 MB/s | 2.78 MB/s | ||
| Image Compress ST | 4.09 Mpixels/s | 5.56 Mpixels/s | 4.08 Mpixels/s | 5.42 Mpixels/s | ||
| Image Compress MT | 8.12 Mpixels/s | 21.4 Mpixels/s | 7.98 Mpixels/s | 10.5 Mpixels/s | ||
| Image Decompress ST | 6.70 Mpixels/s | 9.37 Mpixels/s | 6.67 Mpixels/s | 9.18 Mpixels/s | ||
| Image Decompress MT | 13.2 Mpixels/s | 20.3 Mpixels/s | 13.0 Mpixels/s | 17.9 Mpixels/s | ||
| Lua ST | 257.2 Knodes/s | 417.9 Knodes/s | 257.0 Knodes/s | 406.9 Knodes/s | ||
| Lua MT | 512.3 Knodes/s | 1500 Knodes/s | 505.6 Knodes/s | 810.0 Knodes/s | ||
| FP Score | 920 | 2223 | 915 | 1514 | ||
| Mandelbrot ST | 279.5 MFLOPS | 334.8 MFLOPS | 279.0 MFLOPS | 328.9 MFLOPS | ||
| Mandelbrot MT | 557.0 MFLOPS | 1290 MFLOPS | 550.3 MFLOPS | 648.0 MFLOPS | ||
| Dot Product ST | 221.9 MFLOPS | 477.5 MFLOPS | 221.5 MFLOPS | 455.2 MFLOPS | ||
| Dot Product MT | 438.9 MFLOPS | 1850 MFLOPS | 439.4 MFLOPS | 907.4 MFLOPS | ||
| LU Decomposition ST | 217.5 MFLOPS | 171.4 MFLOPS | 214.6 MFLOPS | 177.9 MFLOPS | ||
| LU Decomposition MT | 434.2 MFLOPS | 333.9 MFLOPS | 437.4 MFLOPS | 354.1 MFLOPS | ||
| Primality ST | 177.3 MFLOPS | 175.6 MFLOPS | 178.0 MFLOPS | 172.9 MFLOPS | ||
| Primality MT | 321.5 MFLOPS | 273.2 MFLOPS | 316.9 MFLOPS | 220.7 MFLOPS | ||
| Sharpen Image ST | 1.68 Mpixels/s | 3.87 Mpixels/s | 1.68 Mpixels/s | 3.86 Mpixels/s | ||
| Sharpen Image MT | 3.35 Mpixels/s | 9.85 Mpixels/s | 3.32 Mpixels/s | 7.52 Mpixels/s | ||
| Blur Image ST | 666.0 Kpixels/s | 1.62 Kpixels/s | 664.8 Kpixels/s | 1.58 Kpixels/s | ||
| Blur Image MT | 1.32 Mpixels/s | 6.25 Mpixels/s | 1.31 Mpixels/s | 3.06 Mpixels/s | ||
| Memory Score | 821 | 1079 | 829 | 1122 | ||
| Read Sequential ST | 312.0 MB/s | 249.0 MB/s | 347.1 MB/s | 364.1 MB/s | ||
| Write Sequential ST | 988.6 MB/s | 1.33 GB/s | 989.6 MB/s | 1.32 GB/s | ||
| Stdlib Allocate ST | 1.95 Mallocs/sec | 2.25 Mallocs/sec | 1.95 Mallocs/sec | 2.2 Mallocs/sec | ||
| Stdlib Write | 2.90 GB/s | 1.82 GB/s | 2.90 GB/s | 1.97 GB/s | ||
| Stdlib Copy | 554.6 MB/s | 1.82 GB/s | 564.5 MB/s | 1.91 GB/s | ||
| Stream Score | 331 | 288 | 335 | 318 | ||
| Stream Copy | 456.4 MB/s | 386.1 MB/s | 466.6 MB/s | 504 MB/s | ||
| Stream Scale | 380.2 MB/s | 351.9 MB/s | 371.1 MB/s | 478.5 MB/s | ||
| Stream Add | 608.8 MB/s | 446.8 MB/s | 654.0 MB/s | 420.1 MB/s | ||
| Stream Triad | 457.7 MB/s | 463.7 MB/s | 437.1 MB/s | 402.8 MB/s | ||
Almost entirely across the board NVIDIA delivers better CPU performance, either as a result of having more cores, having higher clocked cores or due to an inherent low-level Android advantage. Prioritizing GPU performance over a CPU upgrade is nothing new for Apple, and in the case of the A5X Apple could really only have one or the other—the new iPad gets hot enough and draws enough power as it is; Apple didn't need an even more power hungry set of CPU cores to make matters worse.
Despite the stagnation on the CPU side, most users would be hard pressed to call the iPad slow. Apple does a great job of prioritizing responsiveness of the UI thread, and all the entire iOS UI is GPU accelerated, resulting in a very smooth overall experience. There's definitely a need for faster CPUs to enable some more interesting applications and usage models. I suspect Apple will fulfill that need with the A6 in the 4th generation iPad next year. That being said, in most applications I don't believe the iPad feels slow today.
I mention most applications because there are some iOS apps that are already pushing the limits of what's possible today.
iPhoto: A Case Study in Why More CPU Performance is Important
In our section on iPhoto we mentioned just how frustratingly slow the app can be when attempting to use many of its editing tools. In profiling the app it becomes abundantly clear why it's slow. Despite iPhoto being largely visual, it's extremely CPU bound. For whatever reason, simply having iPhoto open is enough to eat up an entire CPU core.
Use virtually any of the editing tools and you'll see 50—95% utilization of the remaining, unused core. The screenshot below is what I saw during use of the saturation brush:
The problem is not only are the two A9s not fast enough to deal with the needs of iPhoto, but anything that needs to get done in the background while you're using iPhoto is going to suffer as well. This is most obvious when you look at how long it takes for UI elements within iPhoto to respond when you're editing. It's very rare that we see an application behave like this on iOS, even Infinity Blade only uses a single core most of the time, but iPhoto is a real exception.
I have to admit, I owe NVIDIA an apology here. While I still believe that quad-cores are mostly unnecessary for current smartphone/tablet workloads, iPhoto is a very tangible example of where Apple could have benefitted from having four CPU cores on A5X. Even an increase in CPU frequency would have helped. In this case, Apple had much bigger fish to fry: figuring out how to drive all 3.1M pixels on the Retina Display.
Facebook
Twitter
RSS
234 Comments
View All Comments
name99 - Friday, March 30, 2012 - link
Just to clarify, this is NOT some Apple proprietary thing. The Apple ports are following the USB charging spec. This is an optional part of the spec, but any other manufacturer is also welcome to follow it --- if they care about the user experience.darkcrayon - Thursday, March 29, 2012 - link
All recent Macs (last 2-3 years) can supply additional power via their USB ports which is enough to charge an iPad that's turned on (though probably not if it's working very hard doing something). Most non-Mac computer USB ports can only deliver the standard amount of USB power, which is why you're seeing this.Your Lenovo *should* still recharge the iPad if the iPad is locked and sleeping, though it will do so very slowly.
dagamer34 - Friday, March 30, 2012 - link
I did the calculations and it would take about 21 hours to recharge an iPad 3 on a normal non-fast charging USB port from dead to 100%. Keep in mind, we're talking about a battery that's larger in capacity than the 11" MacBook Air.snoozemode - Thursday, March 29, 2012 - link
http://www.qualcomm.com/media/documents/files/snap...Aenean144 - Thursday, March 29, 2012 - link
Anandtech: "iPhoto is a very tangible example of where Apple could have benefitted from having four CPU cores on A5X"Is iPhoto really a kind of app that can actually take advantage of 2 cores? If there are batch image processing type functionality, certainly, though I don't know if iPhoto for iOS has this type of functionality. The slowness could just be from a 1.0 product and further tuning and refinement will fix it.
I'm typically highly skeptical of the generic "if the app is multithreaded, it can make use of all of the cores" line of thought. Basically all of the threads, save one, are typically just waiting on user input.
Anand Lal Shimpi - Thursday, March 29, 2012 - link
It very well could be that iOS iPhoto isn't well written, but in using the editing tools I can typically use 60 - 95% of the A5X's two hardware threads. Two more cores, at the bare minimum, would improve UI responsiveness as it gives the scheduler another, lightly scheduled core to target.Alternatively, a 50% increase in operating frequency and an improvement in IPC could result in the same net benefit.
Take care,
Anand
shompa - Friday, March 30, 2012 - link
*hint* Use top on a iOS/Android device and you will see 30-60 processes at all time. The single threaded, single program thinking is Windows specific and have been solved on Unix since late 1960. Todays Windows phones are all single threaded because windows kernel is not good at Multit hreding.With many processes running, it will always be beneficial to have additional cores. Apple have also solved it in OSX by adding Grand central dispatch in their development tools making multithreaded programs easy.
Iphoto for Ipad: Editing 3 million pixel will demand huge amount of CPU/GPU time + memory. Apple have so far been able to program elegant solutions around the limits of ARM CPUs by using NOVA SIMD extensions and GPU acceleration. An educated guess is that Iphoto is not fully optimized and will be at later time.
(the integrated approach gives Apple a huge advantage over Android since Apple can accelerate stuff with SIMDs. Google does not control the hardware and can therefore not optimize its code. That is one of the reasons why single core A4 was almost as fast as dual core Tegras. I was surpassed when Google managed to implement their own acceleration in Andriod 4.X. Instead of SIMD, Google uses GL, since all devices have graphics cards. This is the best feuture in Android 4.x.)
name99 - Thursday, March 29, 2012 - link
[/quote]Apple’s design lifespan directly correlates to the maturity of the product line as well as the competitiveness of the market the product is in.
[/quote]
I think this is completely the wrong way to look at it. Look across the entire Apple product line.
I'd say a better analysis of chassis is that when a product first comes out, Apple can't be sure how it will be used and perceived, so there is some experimentation with different designs. But as time goes by, the design becomes more and more perfected (yes yes, if you hate Apple we know your feelings about the use of this word) and so there's no need to change until something substantial drives a large change.
Look, for example, at the evolution of iMac from the Luxo Jr version to the white all-in-on-flatscreen, to the current aluminum-edged flatscreen which is largely unchanged for what, five or six years now. Likewise for the MacBook Pro.
Look at the MacBook Air. The first two revs showed the same experimentation, trying different curves and angles, but Apple (and I'd say customers) seems to feel that the current wedge shape is optimal --- a definite improvement on the previous MBA models, and without anything that obviously needs to be improved. (Perhaps the sharp edges could be rounded a little, and if someone could work out the mechanicals, perhaps the screen could tilt further back.)
And people accept and are comfortable with this --- in spite of "people buy Apple as a fashion statement idiocy". No-one will be at all upset if the Ivy League iMacs and MBAs and Mac Minis look like their predecessors (apart from minor changes like USB3 ports) --- in fact people expect it.
So for iPhone and iPad. Might Apple keep using the same iPhone4 chassis for the next two years, with only minor changes? Why not? There's no obvious improvement it needs.
(Except, maybe, a magnet on the side like iPad has, so you could slip a book-like case on it that covered the screen, and switched it on by opening the book.)
Likewise for iPad.
New must have features in phones/tablets (NFC? near-field charging? waterproof? built-in projector like Samsung Beam?) might change things. But absent those, really, the issue is not "Apple uses two year design cycles", it is "Apple perfects the design, then sticks with it".
mr_ripley - Thursday, March 29, 2012 - link
"In situations where a game is available in both the iOS app store as well as NVIDIA's Tegra Zone, NVIDIA generally delivers a comparable gaming experience to what you get on the iPad... The iPad's GPU performance advantage just isn't evident in those cases..."Would you expect it to be if all the games you compare have not been optimized for the new ipad yet? They run at great frame rates but suffer in visuals or are only available at ipad 2 resolutions. The tegra zone games are clearly optimized for Tegra while their iOS counterparts are not optimized for the A5x, so of course the GPU advantage is not evident.
This comparison does not seem fair unless there is a valid reason to believe that the tegra zone games cannot be further enhanced/optimized to take advantage of the new ipad hardware.
I suspect that the tegra zone games optimized for A5x will offer a tangibly superior performance and experience. And the fact that the real world performance suffers today does not mean we will not see it shortly.
Steelbom - Thursday, March 29, 2012 - link
Exactly this.