Mid-2011 MacBook Air processor comparison: Core i5 or Core i7?

I’ve been promising myself for some time now that – as my current MacBook Pro has started to fall to pieces after three year’s perfect service – I would upgrade to a lighter, much more portable MacBook Air as soon as they received a Sandy Bridge processor update.

There is a nice overview of the available options at TechonoBuffalo, whilst MacWorld and Bare Feats are the first places I’ve seen with useful(*) benchmarks. Furthermore, the ever-reliable Storage Review has an interesting set of figures for the (excellent) performance of the new Blade SSDs.

However, what I’ve been unable to find elsewhere (and even wikipedia isn’t overly useful, in this case) is any quantitative comparison of the two MacBook Air processor options: For the 128GB 11″ model, the Core i7 processor is a £150 (~15%) extra for – on the face of it, a 200MHz (a fifth of an iPhone 4 or iPad, or 12.5%) speed increase.

There must be more of an advantage, surely?

As it turns out, the answer is yes and no…

Both processors now support HyperThreading (the older Core i5s didn’t) so that either machine will appear to have four cores available. The Core i7 option will TurboBoost up to 2.6GHz, or 2.9GHz if only one core is active. The Core i5 boosts to 2.1GHz or 2.3GHz – but the real-world difference this might make is entirely dependent on work-load: A higher speed leads to higher temperatures, which cause the processor to clock itself down again to remain within it’s defined thermal envelope – so whilst a brief increase in speed may hit the first number, a sustained processing workload will likely fast fall-back to stock speeds.

The Core i7 integrated Intel HD Graphics 3000 is clocked at 1.2GHz, 50MHz faster than the 1.15GHz variant in the Core i5: unless you’re wanting that extra 1fps for benchmarking, I suspect that this will make no discernible difference.

As a side-note, it appears that the HD 3000 graphics are largely on a par with the ageing but well-respected nVidia 320M GPU used in recent Mac Minis and Macbook Pros. It should certainly be an improvement over the older nVidia 9400M or ATI graphics options (and, in the case of the nVidia chipsets, may also encounter fewer driver issues…)

The Core i7 has 4MB of L3 processor cache, whilst the Core i5 has 3MB – both have only 256k of L2 cache. This cache is also shared with the HD 3000 so, whilst larger caches were generally only of significant benefit when running specific compute-intensive processes entirely from cache, the larger cache may aid graphics performance a little. Note that HD 3000 graphics don’t support OpenCL GPGPU processing – the most likely area to benefit from fast cache.

With the addition of FileVault2 full-disk encryption (which, on a laptop intended for mobile use, would appear to be a key feature – but runs the risk of becoming an I/O performance-killer) it is good to see that both of the processor options support AES-NI instruction-set extensions to greatly accelerate AES encryption and decryption. Use of these extensions could greatly mitigate the drop in performance due to decryption and – crucially – encryption on disk writes. At this point, however, there is no confirmation that Apple has actually made use of AES-NI instructions in FileVault2 (and evidence that FileVault in Snow Leopard did not use these optimisations) – but drop-in acceleration support is such a no-brainer and FileVault2 a significant feature in Apple’s marketing that if acceleration isn’t already present then it would be surprising if it isn’t soon soon added in an OS X Lion update.

The AES instructions also form part of Intel’s vPro business-focussed management features, which only the Core i7 option supports. However, it is unlikely that – even with processor support – the MBA includes the necessary hardware to give any meaningful support to these features. Intel’s TXT “Trusted Execution Technology” might be of interest to further secure the FileVault2-enabled boot process, but this requires a TPM chip (which may be integrated in the Northbridge/PCH) – but the product page for the Intel Cougar Point PCH seems to indicate that support is optional, and therefore unlikely to be supported by Apple on a BTO-only configuration.

(The other change, albeit a niche one, is only of interest if using Parallels or VMware Fusion for virtualisation: whilst the Core i7 CPU includes support for Intel VT-d, the Core i5 does not. Lack of VT-d disallows PCI Passthrough, which allows near-native I/O speeds when accessing hardware such as ethernet controllers, graphics cards, and hard drives. Even with these instructions, support may be patchy: Support in the chipset (see above) is only optional, it’s unclear whether Apple enables VT-d support on machines other than Mac Pros (and previously Xserves), whilst VirtualBox explicitly state that PCI Passthrough would be difficult to implement given their existing design-decisions. For Parallels and Fusion, the situation isn’t clear, although Parallels did last year say on their support forums that they were “looking in to” VT-d support and there has since been a major release)

See the official Intel processor comparison chart here.

In summary, the Core i7 option will be faster, but probably not noticeably so under many circumstances – for reading email and light web-browsing, there will likely be no difference.

Although the Core i7 itself supports some interesting fringe technologies, they are almost certainly not supported with Apple’s platform configuration.

In the end the Core i7, whilst only running with a slightly raised clock-speed compared to the Core i5 option, turbos up to a significantly higher speed (2.6GHz versus 2.1GHz – the higher maximum speeds of 2.9GHz and 2.3GHz are only possible for limited periods when only a single core is active. Additionally, it is well-known that the Microsoft Windows scheduler tends to distribute tasks over processor cores in a way which makes this situation very unlikely to occur unless the processor affinity for tasks in the registry is updated from the default settings. Mac OS X’ behaviour in this regard isn’t well understood, at least partially due to a lack of availability of first-party diagnostic tools from Intel). Given that FileVault2 performance is predicated upon having spare CPU cycles available to encode written data (reading is relatively simpler with today’s processor speeds and specialist encryption extensions) then a processor with more headroom may give a more pleasant experience, if this feature enabled.

(*) e.g. ones which don’t involve only GeekBench (which is entirely synthetic, and makes no comment as to real-world performance) or Xbench (which apparently doesn’t work properly on Lion, just yet).