The iPhone 5 Review
by Anand Lal Shimpi, Brian Klug & Vivek Gowri on October 16, 2012 11:33 AM EST- Posted in
- Smartphones
- Apple
- Mobile
- iPhone 5
Apple's Swift: Visualized
Section by Anand Shimpi
Based on my findings on the previous pages, as well as some additional off-the-record data, this is what I believe Swift looks like at a high level:
Note that most of those blocks are just place holders as I don't know how they've changed from Cortex A9 to Swift, but the general design of the machine is likely what you see above. Swift moves from a 2-wide to a 3-wide machine at the front end. It remains a relatively small out-of-order core, but increases the number of execution ports from 3 in Cortex A9 to 5. Note the dedicated load/store port, which would help explain the tremendous gains in high bandwidth FP performance.
I asked Qualcomm for some additional details on Krait unfortunately they are being quite tight lipped about their architecture. Krait is somewhat similar to Swift in that it has a 3-wide front end, however it only has 4 ports to its 7 execution units. Qualcomm wouldn't give me specifics on what those 7 units were or how they were shared by those 4 ports. It's a shame that Intel will tell me just how big Haswell's integer and FP register files are 9 months before launch, but its competitors in the mobile SoC space are worried about sharing high level details of architectures that have been shipping for half a year.
Apple's Swift core is a wider machine than the Cortex A9, and seemingly on-par with Qualcomm's Krait. How does ARM's Cortex A15 compare? While the front end remans 3-wide, ARM claims a doubling of fetch bandwidth compared to Cortex A9. The A15 is also able to execute more types of instructions out of order, although admittedly we don't know Swift's capabilities in this regard. There's also a loop cache at the front end, something that both AMD and Intel have in their modern architectures (again, it's unclear whether or not Swift features something similar). ARM moves to three dedicated issue pools feeding 8 independent pipelines on the execution side. There are dedicated load and store pipelines, two integer ALU pipes, two FP/NEON pipes, one pipe for branches and one for all multiplies/divides. The Cortex A15 is simply a beast, and it should be more power hungry as a result. It remains to be seen how the first Cortex A15 based smartphone SoCs will compare to Swift/Krait in terms of power. ARM's big.LITTLE configuration was clearly designed to help mitigate the issues that the Cortex A15 architecture could pose from a power consumption standpoint. I suspect we haven't seen the end of NVIDIA's companion core either.
At a high level, it would appear that ARM's Cortex A15 is still a bigger machine than Swift. Swift instead feels like Apple's answer to Krait. The release cadence Apple is on right now almost guarantees that it will be a CPU generation behind in the first half of next year if everyone moves to Cortex A15 based designs.
Facebook
Twitter
RSS
276 Comments
View All Comments
A5 - Tuesday, October 16, 2012 - link
I don't think there's a good way to measure storage performance on the iPhone. Also not really sure why it matters.repoman27 - Tuesday, October 16, 2012 - link
I timed how long it took to transfer my music library, and clocked 11.1 MB/s writing to the user area of a 64GB model. So no significant change from previous iPhones, and still pretty typical for a smartphone. I'd be interested to get some gauge of the read speeds.And @A5, storage performance affects boot and application load times as well as sync and backup. With a 64GB model, syncing can take quite a while.
name99 - Wednesday, October 17, 2012 - link
Transferring the music library is a LOUSY choice for speed measurement because (depending on your iTunes settings) you may be transcoding all your music to a lower bit rate to fit more on the iPhone; so you are gated by the transcoding performance, not the flash write speeds. I transcode my music (most in Apple lossless on my iMac) to 192kbps AAC for my iDevices, and on my ancient iMac it is the transcoding that throttles performance.A much better situation to look at is transferring large movies. On my devices
- iPhone 4 writes at about 18MB/s
- iPad3 writes at about 22MB/s
Over the last 6 months Anand occasionally has published flash numbers for Android phones and they're generally around half these Apple numbers.
repoman27 - Wednesday, October 17, 2012 - link
Believe you me, I don't allow iTunes to transcode anything, except to ALAC on occasion. But yes, that number I gave was on the low side, but probably more due to it being thousands of files as opposed to one large sequential write.I just transferred a large video file back and forth directly to and from the user storage area of one of my apps, and came up with numbers that are more in line with yours. 23.84 MB/s avg read and 20.05 avg write.
Most MLC NAND modules capable of 20 MB/s writes should be able to do at least 40 MB/s on sequential reads, which leads me to believe that we're still gated to around 25 MB/s by the NAND interface here, which is kinda bogus.
Spunjji - Friday, October 19, 2012 - link
name99, that is not a "better situation" because the performance figures you quote only apply to large block file transfers. It's no more real-world than the figures repoman quoted, which are not "LOUSY". Both are valid, so ideally a proper test should mix both types of data.Furthermore, the idea that your admittedly ancient iMac being crap at transcoding MP3s somehow invalidates somebody else's testing is ridiculous as well. With any decent system that would only be the case if you were shifting data to a device a *lot* faster than any smartphone NAND.
So, you may need to rethink your "victory" a little more.
KPOM - Wednesday, October 17, 2012 - link
I've had my iPhone since 9/22 and there is not a single scuff on it. My guess is that in the rush, some units got through QC, but the phone itself isn't any more prone to scratching in normal use than other phones. Meanwhile, Apple being Apple, they have held up production to improve QC even if it means fewer sales in the short run.rarson - Wednesday, October 17, 2012 - link
You've had it less than a month. There shouldn't be any scuffs on it."Apple being Apple"
Ha! That's a good one!
Spunjji - Friday, October 19, 2012 - link
Trololololol"Mine is fine so everyone else is lying". <- Possibly my favourite bogus argument ever. Apple the generous indeed...
doobydoo - Saturday, October 20, 2012 - link
Because it's so much more compelling than the 'Mine is scratched so everyone elses must be'?lukarak - Wednesday, October 17, 2012 - link
But it doesn't rust. It scratches if it comes in contact with something harder. Just as a car does. Would you buy a car that gets a scratched bumper when you hit a wall? Well, maybe you wouldn't but people do. Regularly.This iPhone is no different than every other iPad, MBP or MBA or the first Al MB. Or any other device constructed from aluminium. They scratch if they are brushed against something. It's just normal.