Apple’s iOS 64-bit iUpgrade: Don't expect a 2x performance leap
The iPhone 5S has a 64-bit processor, but will it really make any difference?
What are the implications of Apple’s 64-bit ARM A7 processor for the iPhone user who upgrades to the new 5S? Not as many as you might think.
Apple has said the chip is compatible with all the iOS software out there that is still 32-bit. For the moment, at least, that is all third-party programs.
Apple hasn’t said how much RAM the 5S contains, but it’s not going to be of the order that the new 64-bit chip makes possible.
As it stands, software running on the 32-bit ARM processor family used by Apple can access up to 4GB of virtual memory, and the chip can potentially access up to 1TB of physical memory (thanks to a 40-bit physical address width).
But there’s no sign iPhones will gain that much RAM in the near future and certainly not the 256TB of physical memory the new A7 can address: although pointers into virtual memory can be 64-bit wide on that new processor, the chip's architecture defines a 48-bit physical address system [PDF].
Software could use some extra headroom with 64-bit pointers, although that may boil down to effectively 48 bits of useful virtual address space per app (the upper bits being reserved for the operating system and unmapped space).
So why bother with a 64-bit chip at all? The cynic might say, not unreasonably, that it’s nothing more than a marketing exercise. Certainly Apple is very keen to claim it was the first and – for now – the only phone maker to put a 64-bit chip in a smartphone. It’ll make the same claim for tablets when it upgrades the iPad to the A7 chip shortly.
But Apple is also pitching improved performance: up to twice the performance of the 32-bit A6, it says. To provide that boost, the A7 contains twice as many integer and floating-point registers as its predecessors do. That allows the chip to be loaded with more data at once, in turn meaning there need be fewer subsequent cache or memory accesses. The result is that the core’s arithmetic units spend less time standing idle awaiting numbers to crunch.
Apple is telling iOS app developers that focusing on the use of 64-bit integer maths is a particularly good way to take advantage of the new chip. Likewise making use of ARM’s NEON instructions, the architecture’s answer to Intel’s SSE single instruction multiple data operations.
Apple’s A7 chip is based on ARM’s ARMv8 design, which also incorporates instructions to accelerate the AES and SHA-1/SHA-256 cryptography algorithms [architecture overview PDF]. Apple itself is likely to be using these in its Touch ID biometric control mechanism.
Those third-party apps are going to sloooow right down
These advantages are all well and good for 64-bit apps, but not for 32-bit code. Apple itself admits that 32-bit code won’t run as quickly or as efficiently on the A7 as a 64-bit version of the software will. That said, implementing 64-bit code has a downside too: when your data units are twice as big – a long integer takes up four bytes on an A6-based iPhone, but eight bytes on an A7 device, for example – you need twice as much memory to store the same amount of information.
As I say, Apple’s iPhone 5s tech specs don’t reveal how much memory has been built into the 5S, but 2GB, double the RAM fitted to the A6 and A6X chips, seems likely, especially given Apple’s claim the A7 has more than a billion transistors on board.
And not just RAM. Using more bytes to store a value also means the host chip’s caches effectively become less capacious, and that can degrade performance too. Again, Apple hasn’t revealed how big are the A7’s caches, though it’s widely being assumed for the moment that the A7 contains the same 32KB instruction and data caches, and 1MB L2 cache as the A6.
When the iPhone 5S launches a 32-bit app, iOS 7 has to load 32-bit versions of any system frameworks that the app uses. That’s in addition to the 64-bit versions of those libraries the operating system may already have loaded into memory. Again, this increases the active app’s memory footprint, meaning the OS needs to be more aggressive in parking background apps out of RAM and into the Flash storage. Having both 32-bit and 64-bit copies of all the system frameworks increases the amount of storage space the OS takes up too, though fortunately even on a 16GB iPhone 5S, it shouldn’t prove much of a hindrance to filling a phone with apps and content.
All of Apple’s own apps, it says, have been recompiled to work with the 64-bit iOS runtime, so it really will be third-party apps that slow the system down. No wonder Apple is keen for coders to begin upgrading their apps to include 64-bit code – iOS app binaries can contain both 32- and 64-bit versions – the former for compatibility with older kit – but that code very likely needs to be optimised for the 64-bit environment to make sure it gets the most out of the performance advantages the A7 offers.
That increased battery life? Not going to happen. Here's why
Of course, given how many third-party apps are out there, it’s going to take some time for a significant percentage to support the new 64-bit runtime. There are many apps available today that were designed for much earlier versions of iOS and may not get iOS 7 makeovers let alone 64-bit conversions. Even apps that are updated this way may not show an immediate twofold performance increase of the kind Apple is highlighting.
That’s why users are unlikely to see any obvious increase in battery life. Faster performing apps get the work done more quickly than they once did and that allows the processor to spend more time in a low-power state, reducing the drain on the battery. If those faster-performing apps aren’t there, that’s not an advantage users will see.
Of course, recasting iOS as a 64-bit operating system puts it on a par with Mac OS X, which migrated to 64-bit in 2006. That might suggest closer integration of the two operating systems, though there’s plenty of code in each that’s not relevant to the usage model of the other.
iOS-based laptops? It’s possible, and perhaps Apple is daft enough to make the same mistake Microsoft did: trying to make the primary UI of a keyboard-based device a tablet-centric one. ®