Hell Freezes Over: Evaluating the Move to Intel

So Apple are moving to Intel x86 chips.

I’m still rather reeling from the news. Being generally of a more cynical bent, I was inclined to go along with John Gruber’s various debunkings of the hype that so often precedes a WWDC. Shurely shome mishtake, I thought.

Evidently not. Unless Steve is just trying to see just how far the Reality Distortion Field will go, this is the real deal. Developers will get their hands on the goods now (including an updated version of Xcode (2.1.) which will ease the transition though, amongst other things, the creation of fat binaries, i.e. those that support both PPC and x86), and consumers starting in a year’s time, with the transition of the consumer line complete by June 2007. There will be software to handle the running of PPC binaries on x86.

But what does this all mean? What are the implications? Upsides and downsides?

Prior Art
Apple is no stranger to big upheavals. As Steve pointed out in his keynote, the Mac has previously gone through two radical changes: from the Motorola 68k line of CPUs to the PowerPC, a transition made possible through emulation and the use of fat binaries; and from OS 9 to OS X, arguably the more technically complicated of the two transitions and managed again using emulation. Though there are more than a few ‘old guard’ Mac users who were unhappy with the move to OS X, there can be no doubt that it was achieved with a quite impressive grace. There was little real pain.

So this isn’t the first time.

But things are a little different here. Although Xcode can easily facilitate fat binary creation and Cocoa code will port without great issue, there is still a lot of Carbon cruft on the Mac – indeed, there is much in Apple’s own apps, QuickTime perhaps being the most notable example, but iTunes too, and there are others. This Carbon code will be harder to port, because it’s a lot more closely tied to the architecture of the system than is Cocoa code. But this a problem for developers, and so in the general scheme of things, not so much of an issue.

Users should hopefully see very little difference. Using a technology called Rosetta, which Steve described as a ‘dynamic binary translator’, applications written for the PowerPC should run emulated without any problems. The only issue here, as with the move from 68k to PPC, is one of speed, and it will be very interesting to see how Apple copes with the oft-cited ‘lack of registers’ issue when the talk turns to emulation of PPC on x86. Perhaps they are hoping that by then, Intel’s chips will be sufficiently quick as to make most of these concerns irrelevant. Personally, I’m going to wait and see.

It will also be interesting to see how far back backwards compatibility will go. At the moment, I can play games and run software written for 15 to 20 year old Macs – not necessarily particularly useful (but perhaps in some cases crucial), but technically impressive nonetheless, especially when compared to the poor support Windows NT/2000/XP have for DOS software. Will my new Mac still be able to play classics such as the original Prince of Persia?

Speed Parity
Perhaps the greatest advantage that the switch to x86 will bring will be speed parity with the PC world. Whilst the top of the range Power Mac G5 is not an unimpressive machine, packing as it does two 2.7Ghz G5 processors, Intel’s 3.6Ghz chips really have the edge in terms of raw power, and if IBM cannot keep up, Apple has a problem. By using the same CPUs as its any-colour-as-long-as-it’s-beige-or-black box competitors, Apple provides Macs with stunning design and staggering speed.

And this is why having Intel make PowerPC CPUs wouldn’t, upon reflection, make much sense: it doesn’t solve the core problem, namely that Apple is not a big enough player to justify serious development expenditure for its CPU. IBM is now focussing on the needs of what are shortly to become very significant customers – Sony, Microsoft and Nintendo – for they are all using PowerPC chips in their next generation consoles. Apple’s needs – the AltiVec extensions, regular clock speed increases, etc. – are not a major part of IBM’s current game plan. And getting Intel to make PowerPCs would almost certainly still have left Apple somewhat lagging, as Intel would be foolish not to invest the majority of its development budget in bettering the performance of its best-selling processor – the x86.

Windows Emulation
For those still wanting a virtual machine, Virtual PC’s speed will doubtless increase greatly, for it will no longer need to translate between different processor architectures. More interestingly, thanks to the efforts of the Wine team, many Windows applications can already run without recompilation on Linux. A port to PowerPC-based Mac OS X has been in development for a while, but progress has not been quick, and the emulation requirement is obviously challenging. With that obstacle now removed, the “but it won’t run my software” argument suddenly becomes very close to moot. With that, the Mac becomes really competitive vs. Windows.

It is unlikely (as Apple is probably unwilling to so directly compete with Microsoft), but Apple could even contribute developer time and resources to the Wine effort, as it would undoubtedly benefit the platform in the long run.

In a similar vein, games should be much easier to port too, either courtesy of a by-then-quite-advanced Wine, or simply because there is no need to port code to a different processor, which often causes problems in highly optimised code like games. Although the difficulty in porting something from one operating system to another (i.e. Windows to Mac OS X) should not be underestimated (unless, of course, it is written cross-platform in the first place), gaming on the Mac could well become more commonplace. I shall be extremely happy the day I see Grand Theft Auto: Vice City running on a Mac.

What of AltiVec, the stellar vector unit in every G4 and G5 CPU? It seems unlikely that Intel will make processors with AltiVec units specially for Apple, given the fact that it would surely be non-trivial to add AltiVec to x86 chips and would then differentiate Mac processors from those in commodity boxes. What, then, is to happen to all that AltiVec-optimised code?

The answer lies, I presume, in GCC. Though GCC for PowerPC has improved considerably since it became Apple’s compiler of choice for Mac OS X, it isn’t great, and lacks the speed and optimisation of the x86 version, which has the obvious advantage of being the compiler targeting the platform used by the majority of the free software-using world. So although the CPU itself may not be as refined as the PowerPC, lacking as it likely will an AltiVec unit, thanks to a decent compiler Mac OS X on x86 should be pretty quick, and code optimisation should come thick and fast.

Optimisation makes a massive difference too. LAME, the excellent open source MP3 encoder, is very highly optimised for x86, but contains almost no optimisations for the PowerPC, although AltiVec-enhanced versions do exist. Fact is that in cases like this, the x86 version fairly flies along, whilst on the Mac it is embarrassingly slow.

Free Software
I’ve already mentioned three items of free, open source software above – Wine, GCC and LAME – but the move to x86 should make porting more software even easier. Furthermore, just as with the example of LAME cited above, such ported software will benefit from many processor-dependent enhancements, and so should be quicker. And that’s never a bad thing.

Whilst it’ll be interesting to see the effect that this has on Apple’s profits this year (especially at a time when iPod demand is flat or falling), the move is certainly good for the future, and in time, will likely really make for decent competition with Microsoft’s Windows hegemony.

But as to that, only time will tell.

You're subscribed! If you like, you can update your settings


Comments have been disabled for this post