Apple: Up the Market without a CPU

- by Paul Murphy -

For the last three weeks I've been talking about the impact the new Sony, Toshiba, and IBM cell processor is likely to have on Linux desktop and data center computing. The bottom line there is that this thing is fast, cheap, and deeply reflective of very fundamental IBM ideas about how computing should be managed and delivered. It's going to be a winner; probably the biggest thing to hit computing since IBM's decision to use the Intel 8088 led Bill Gates to drop Xenix in favor of an early CP/M release with kernel separation hacked out.

Sun has the technology to compete. Its throughput computing initiative coupled with some pending surprises on floating point give it the hardware cost and performance basis needed to compete on software where it has the best server to desktop story in the industry.

No one else does. Microsoft's software can't take x86 beyond some minor "hyperthreading" on two cores without major reworking and Itanium simply doesn't cut it. The Wintel oligopoly could spring a surprise - a multi core CPU made up from the RISC like core at Xeon's heart along with a completely rewritten Longhorn kernel to use it- but no one's reported them stuffing this rabbit into their hat, so for now at least they seem pretty much dead ended.

If, as I expect, the Linux community shifts massively to the new processor, Microsoft and its partners in the Wintel oligopoly will face some difficult long run choices. It's interesting, for example, to wonder how long key players like Intel and Dell can survive as stand-alone businesses once the most innovative developers leave them to Microsoft's exclusive mercy.

Wintel's dilemma is, however, a fairly long term issue; much closer at hand is Apple's immediate problem. Just recently Steve Jobs has had to apologise to the Apple community for not being able to deliver on last year's promise of a 3Ghz G5 by mid 2004. IBM promised to make that available, but has not done so. A lot of people have excused this on the grounds that the move to 90nm manufacturing has proven more difficult than anticipated but I don't believe that. PowerPC does not have the absurd complexities of the x86 and 90nm production should be easily in reach for IBM. The cell processor, furthermore, is confidently planned for mass production at 65nm early next year.

This will get more interesting if, as reported on various sites including Tom's hardware, IBM has been burning the candle at both ends and will also produce a three way, 3.5Ghz version of the PowerPC for use on Microsoft's X-Box. Whether that's true or not, however, my belief is that IBM chose not to deliver on its commitment to Apple because doing so would have exacerbated the already embarrassing performance gap between its own server products and the higher end Macs. Right now, for example, Apple's 2Ghz X-serve is a full generation ahead of IBM's 1.2Ghz p615, but costs about half as much.

Unfortunately this particular consequence of Apple's decision to have IBM partner on the G5 is the least of the company's CPU problems. The bigger issue is that although the new cell processor is a PowerPC derivative and thus broadly compatible with previous Apple CPUs, the attached processors are not compatible with Altivec and neither is the microcode needed to run the thing. Most importantly, however, the graphics and multi-processor models are totally different. As a result it will be relatively easy to port Darwin to the new machine, but extremely difficult to port the MacOS X shell and almost impossible to achieve backward compatiblity without significant compromise along the lines of a "fat binary" kind of solution.

In other words, what seemed like a good idea for Apple at the time, the IBM G5, is about to morph into a classic choice between the rock of yet another CPU transition or the hard place of being left behind by major market CPU performance improvements.

Look at this from IBM's perspective and things couldn't be better. Motorola's microprocessor division (now Freescale Semi-conductor) is mostly out of the picture despite having created the PowerPC architecture. Thus if Apple tries to stay with the PowerPC/Altivec combination it can either be performance starved out of the market or driven there by the costs of maintaining its own CPU design team and low volume fabrication services. If, on the other hand, Apple bites the bullet and transitions to the cell processor, IBM will gain greater control while removing Apple's long term ability to avoid having people run MacOS on non Apple products. Either way, Apple will go away as a competitive threat because the future MacOS will either be out of the running or running on IBM Linux desktops.

I think there'll be an interesting signal here. If IBM thinks Apple is going to let itself be folded into the cell processor tent, it will probably allow as many others to clone the new Cell PC as it can make CPU assemblies for. If, on the other hand, IBM thinks Apple plans to hang in there as an independent, it may just treat the Cell PC as its own Mac and keep the hardware proprietary. Notice, in thinking about this, that they don't have to make an immediate decision: there will be CPU assembly shortages for the first six months to a year if not longer.

So what can Apple do? What they should have done two years ago: hop into bed with Sun. Despite its current misadventure with Linux, Sun isn't in the generic desktop computer business. The Java desktop is cool, but it's a solution driven by necessity, not excellence. In comparison, putting MacOS X on the Sunray desktop would be an insanely great solution for Sun while having Sun's sales people push SPARC based Macs onto corporate desktops would greatly strengthen Apple.

Most importantly, SPARC is an open specification with a number of fully qualified fabs. In the long term Apple wouldn't be trapped again and in the short term the extra volume would improve prospects for both companies. Strategically, it just doesn't get any better than that.

There are three important footnotes:

  1. I am not suggesting Sun buy Apple, or Apple buy Sun. Neither company has adequate management bandwidth as things stand. I'm suggesting informed co-operation, not amalgamation.

  2. The transition to SPARC would be easier than the transition to Cell. It may look like the bigger change, but the programming model needed for cell is very different whereas existing MacOS software, from any previous generation, need only be re-compiled to run on SPARC. In particular, the graphics libraries delivered with the cell PC will likely focus on Gnome/KDE compatibility to make porting applications for them easy, but Apple would have to re-invent its interface management libraries at the machine level - something it would not face in a move to SPARC where PostScript display support is well established.

    In addition, existing Sun research on compiler automation suggests that multi-threaded CPUs like Niagara and Rock, could automatically convert PowerPC and even MC68000 executables to SPARC on the fly - meaning that "fat binaries" would not be needed although a MacOS 9.0 compatibility box would probably still make sense.

  3. People I greatly respect tell me that Sun's throughput computing direction isn't suited to workstations like the Mac where single process execution times are critical to the user experience. The more I study this question, the more I disagree. Fundamentally this issue is about software, not hardware.

    Consider, for example, what could be achieved with the shared memory access and eight way parallism inherent in the light weight process model Sun is building into products like Niagara. This won't matter for applications like Microsoft Word, where the 1.2Ghz nominal rate is far faster than users need anyway, but can make a big difference on jobs like code compilation, JVM operations, or image manipulation in something like Adobe's Photoshop. Given the much higher cache hit rates and better I/O capabilities offered by the relatively low cycle rate, theory suggests that truly compute intensive workstation software could hit somewhat better than 85% system utilization - meaning that an eight way Niagara-1 running at 1.2Ghz would easily outperform a Pentium four at 8Ghz.

    Making that happen would, of course, take serious software change, but if the preprocessors now thought to be under development at Sun work as expected most of that would be automated -thereby greatly reducing the barriers to effective CPU utilization on the Mac for PC oriented developers like Adobe.


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 20-year veteran of the IT consulting industry.