Apple's <i>Grand Central</i> threat to Microsoft

Apple's quiet preview of OS X.6 - Snow Leopard - promises ". . . unrivaled support for multi-core processors . . . " through a "new set of technologies" named Grand Central. What makes Grand Central so powerful - and how can Microsoft respond?

Fresh from Google's Seattle Scalability Conference - which focused on just the questions Grand Central purports to answer - Apple has only so many choices. What are they?

Peeling the Apple Apple is clearly a leader in implementing multi-core support, beginning with the first dual processor Power Macs 5 years ago, while the DayStar multi-processor Macs date back to the mid-90s.

The situation is more urgent today: multi-core systems are the only easy way to drive performance up while controlling power use. The problems of multi-processor systems have been studied for over 30 years.

The chief issue is scalability: does an additional processor add performance that exceeds the cost of the processor?

Alternatives Compiler technology is capable of decomposing applications into appropriate multiple jobs that can be spread over multiple processors. The real issues are coordinating those jobs and their access to storage - either RAM or disk.

The common approach is to manage the multiple jobs as threads and access to storage as locks. The problem is that the overhead of managing those threads and locks grows with the number of processors - limiting scalability.

Another approach - used in Azul Systems 800+ core Java compute servers - is something called Transaction Memory. Instead of locking file or memory access, TM treats memory much like databases treat commits: as atomic transactions that are either completed or rolled back.

Grand Central could also include a more elegant scheduler - like ULE that promise better performance under load. Or improved compilers such as Cray's Chapel, whose knowledge of multi-core architecture makes it much simpler for programmers - something Grand Central promises.

Microsoft's problem Whether Windows 7 is simply perfuming the Vista pig or a significant re-write, Apple's Grand Central challenge can't be ignored. If Apple achieves real speed-ups and Microsoft doesn't they will look like a pitiful, helpless giant. And their IT defenders will look like idiots.

Windows 7's rapid development schedule suggests a marketecture refresh rather than a fundamental re-write. For a much smaller company to steal the lead in multi-core performance would be a long-remembered humiliation. Imagine the PC guy vs Mac ads.

The Storage Bits take Apple is likely working on all these technologies. With Sun's powerful Dtrace tool standard in OS X, they have the means to assess all options and choose the winners next year.

Update: Another element in the mix is Intel's Digital Enterprise Group, whose paper Enabling Scalability and Performance in a Large Scale CMP Environment [available from the ACM] discusses a project that

. . . enables near linear improvements in performance and scalability for desktop workloads such as the popular XviD encoder and a set of RMS (recognition, mining, and synthesis) applications. Another key contribution of this work is its use of McRT to explore non-traditional system configurations such as a light-weight executive in which McRT runs on "bare metal" and replaces the traditional OS.

[Emphasis added]

BTW, McRT - Multi-core Run Time - is pronounced "MAC-ar-tee."

Intel is stirring this pot because they know that their advanced hardware is useless without software. They also know that Microsoft and Dell won't invest a nickel in advancing computing's state-of-the-art because they are very happy with the status quo. Supporting Apple makes good business sense for Intel - and for anyone interested in a competitive computer market. End update.

Microsoft has a deep technical bench, but their executive leadership can't seem to prioritize. Just as Henry Ford lost a 25 year lead in automobiles through inflexibility, Microsoft's cavalier attitude towards Windows customers is steering them to disaster.

Comments welcome, of course. I want fast multi-core performance and I don't care who delivers it first.