On Apple’s A7 Processor

There was a rumor today that the iPhone 5S will be powered by an A7 processor which is dual core, 64-bit and 31% faster than the subsystem in the current iPhone 5.

While people speculate on the innards of the chip, it’s a good time to take a step back and look at how Apple approaches hardware / software and internal System-on-Chip (SoC) development.

One of the biggest—if not the biggest—advantages Apple has in not being reliant on merchant silicon (they don’t buy standard application processors designed by others) is that they can customize the A7/A8 etc to exactly fit their own apps / services frameworks, without making generic design compromises.

To see this best, contrast Qualcomm, whose processors will fit in hundreds or thousands of different Android models to Apple, whose A7 will go in to the iPhone, iPad and possibly the iPod and iTV.  Because Qualcomm must support so many potential vendor configurations, they are forced to design by the 80/20 rule. Meanwhile, Apple can strip out absolutely everything it doesn’t want on-chip, and add specific things it does, such as DSP or graphics capabilities which iOS is designed to use.

Will Apple remain with 2 cores in the A7 or go to 4, and more importantly, how do they decide?

Today there are three main requirements driving the trend to multicore architectures: low power, performance and system / memory bandwidth.  But mobile platforms are not about raw performance, they are about performance per Watt of power consumption.

To use an analogy, a multi-core processor is like cooking a meal in separate pots on 4 different stovetop burners, instead of in 1 super-size pot on a large flame. Each pot cooks independently, which allows the chef to better manage ingredients and temperature—e.g. you can turn off a couple burners (save gas) or move pots around as you focus on different portions of the meal.

The tradeoff is software. You have to have a smart “chef”. The chip not only has to employ its own on-board intelligence to manage inter-processor communication between cores, but it also has to make compile and run time decisions on what parts of code are run on which processor.  This results in a lot of software complexity. Standard software design techniques are not well suited to deal with these inherent complexities. In fact, it’s well known that software parallelism is the single biggest challenge to computing design today.

These design challenges effectively sit in the software architecture stack around app design, debugging, optimization and API design. Above the OS you need tightly coupled drivers and applications that can take advantage of the underlying hardware. Since increased “free” performance from the addition of more cores is offset by these software complexities, the company with the tightest integration across the stack wins the performance per Watt game.

For example, in Facebook’s iOS app, they use a main thread to drive UI and handle touch events, and another thread to manage other computationally expensive tasks in the background. The background thread handles things like network activity and JSON parsing, while not slowing down the main UI thread.

So basically different threads are being handled by different cores. Code certainly doesn’t just compile magically in all cases to take advantage of chip design on modular platforms like Android. The better that compilers and APIs are designed to fit the underlying  OS and chip / driver stack, the easier it is for devs to extract highest performance per Watt. App developers like FB need to optimize the hell out of the code (they wrote a blog post on how they did for iOS). And they desperately want a platform that makes it easy to do so, like Apple’s.

Yes, we know Apple isn’t the best at services today and that Google, Spotify, Dropbox and others are eclipsing them here. But in terms of OS-level hardware / software design, Apple is definitely best in world. They can wield tremendous advantage by having their own chip and software teams collaborate – Apple pioneered parallel software efforts in GCD and OpenCL.

We’ll see in two weeks what the iPhone 5S and A7 processor bring, but whether the chip is dual or multicore, 32-bit or 64, you can bet Apple has it all tightly woven together. Developers simply love Apple’s tools. These advantages, along with service-layer issues brought on by Android fragmentation, may easily be enough to keep Apple ahead into the next generation of the mobile platforms war.