Saturday, September 14, 2013

Apple's 64-Bit Gimmick

On Tuesday, Apple unveiled its latest iPhones. Powering the iPhone 5s (boy, I really wish they hadn't decided to use a lowercase 's' here) is a new system on a chip, the A7, that Apple is touting as the first 64-bit processor in a smartphone. Predictably, nerd rage ensued.

Zeroing in on the fact that the iPhone 5s is unlikely to ship with more than 2 GB of RAM, internet commentators instantly attacked the 64-bitness of the A7 as a marketing gimmick, something for Apple to brag about even when its users or developers wouldn't actually see any benefits. Drawing this conclusion was somewhat understandable since the main reason cited for switching from 32-bit to 64-bit processors on the desktop was always the ability to address more than 4 GB of RAM. (Of course, the reasonable thing to do would have been to engage in a bit of inquiry and to ask yourself why Apple might have made this decision instead of ridiculing a decision you don't have the technical knowledge to understand — but no one has ever accused internet commentators of being reasonable.)

A number of experts stepped up in an effort to counter this misconception, explaining that the transition to 64-bitness also meant a transition to larger registers and a more efficient instruction set, the ARMv8. A second round of articles were published, but the internet commentators wouldn't hear it. Some people are simply so invested in the idea that Apple is not an engineering company that it is utterly inconceivable to them that Apple could have engineered anything first.

The funny thing is, first is completely irrelevant and the A7 demonstrates exactly how much of an engineering company Apple actually is. Everyone could see that 64-bit processors were coming. It is on ARM's roadmap. Samsung could have done it first, but they bet on the 32-bit Cortex-A15 instead. Qualcomm could have done it first; they certainly have the design chops to roll their own custom core. But if either Samsung or Qualcomm had done it first, it would have been a gimmick, and that's not a double standard.

People have argued that the experts are overstating the benefit of larger registers and the more efficient ARMv8 instruction set because programs would have to be recompiled to take advantage of these features. But while that might be difficult to do on Android, Apple has engaged in a multiyear effort to transition its toolchain from GCC to Clang/LLVM and they have also worked to get the vast majority of their developers on Cocoa frameworks for exactly this kind of flexibility. Apple didn't do these things because it was sexy or made good marketing. They learned from their transitions from Carbon to Cocoa, and from PowerPC to Intel. How much do you want to bet that iOS 7 is already running on ARMv8 and has been for some time? To me, that is good engineering.

When Apple designed the iPad 3 with a retina display, they doubled the size of the battery and tripled the performance of the GPU. Increasing the screen resolution from 1024 x 768 to 2048 x 1536 meant doubling the backlighting in order to maintain screen brightness. Since the backlights account for about 80% of the power consumed by a tablet, the battery had to be doubled to maintain battery life. The iPad 2 already had the best GPU of any tablet, but the iPad 3 would have to push four times as many pixels. Apple was unable to quadruple GPU performance in one year, but they got surprisingly close. This meant that some games would run at lower frame rates on the iPad 3 than on the iPad 2.

In contrast, when Android tablets moved to high-resolution displays, there was little effort to maintain battery life or performance. In other words, there was little engineering. OEMs simply slapped new displays on existing designs. It'll be interesting to see how Android makes the transition from 32-bit to 64-bit processors. Samsung and Qualcomm don't control when Google will build Android on ARMv8. I'm not sure who controls the toolchain app developers use, or how readily or quickly app developers will recompile their apps even if the tools are there. Third-party app developers of all sizes on iOS are already preparing to update and recompile their apps for the new UI in iOS 7. Maybe Apple hasn't been sitting on its ass after all.

No comments:

Post a Comment