• silicon.com
• Technology
• Software

By Stephen Shankland, 1 September 2009 12:53

NEWS

Apple began shipping Snow Leopard on Friday but the true importance of the Mac OS X update is likely to emerge much later.

That's because Mac OS X 10.6 begins a long-term attempt by Apple to get ahead by cracking a problem facing the entire computer industry: squeezing useful work out of modern processors. Instead of stuffing Snow Leopard with immediately obvious new features, Apple is trying to adjust to the new reality in which processors can do many jobs simultaneously rather than one job fast.

Apple shed some light on its project, called Grand Central Dispatch, at its Worldwide Developer Conference in June, but most real detail was shared only with programmers sworn to secrecy. Now the company has begun talking more publicly about it and other deeper projects to take advantage of graphics chips and Intel's 64-bit processors.

The moves align Apple better with changes in computing. For years, chipmakers such as Intel and AMD had steadily increased the clock rate of their processors, and programmers got accustomed to a performance boost with each new generation. But earlier this decade, problems derailed the gigahertz train.

First, chips often ended up merely twiddling their thumbs more because slower memory couldn't keep the chip fed with data. Worse, the chips required extraordinary amounts of power and produced corresponding amounts of hard-to-handle waste heat.

And so began the mainstream multicore era, in which processors got multiple computing engines called cores that work in parallel. That's great for some tasks that can be easily broken down into independent pieces but programmers were accustomed to a more linear way of thinking where tasks execute in a series of sequential steps.

Enter Grand Central Dispatch, or GCD. This Snow Leopard component is designed to minimise many of the difficulties of parallel programming. It's easy to modify existing software to use GCD, Apple said, and the operating system handles complicated administrative chores so programmers don't have to.

According to Illuminata analyst Gordon Haff, overall, the computing industry really is only now beginning to tackle parallel programming in earnest. If building mature parallel programming tools is a 10-chapter book, the industry is only at chapter two right now, he said. But with no other alternative, the book will be written.

"It has to happen," Haff said. "If you look at history of information technology, things that have to happen really do happen."

One way programmers have dealt with the arrival of multicore processors - and with the multiprocessor machines that preceded them - is through a concept called threads. There are various types, but generally speaking, a thread is an independent computing operation. For programmers to take advantage of multicore processors, they assign one thread to each core, and away they go, right?

Not so fast. Threads come with baggage. Each requires memory and time to start. Programs should be broken up into different numbers of threads depending on how many cores a processor offers. Programmers have to worry about "locking" issues, providing a mechanism to ensure one thread doesn't change data another thread is already using. And one threaded program might step on the toes of another running at the same time.

Some tools to ease the difficulties, such as Intel Threading Building Blocks, are available, but threads remain complicated.

"We looked at this and said it needs a fundamental rethink. We want to making developing applications for multicore easier," Hodges said. "We're moving responsibility for the management code into the operating system so application developers don't have to write and maintain it."

Blocking and tackling
The core mechanisms within GCD are blocks and queues. Programmers mark code chunks to convert them into blocks, then tells the application how to create the queue that governs how those blocks are actually run. Block execution can be tied to specific events--the arrival of network information, a change to a file, a mouse click.

Apple hopes programmers will like blocks' advantages: Older code can easily be retrofitted with blocks so programmers can try it without major re-engineering; they're lightweight and don't take up resources when they're not running; and they're flexible enough to encapsulate large or small parts of code.

Wiley Hodges, director of Mac OS X marketing, said: "There's a lot of overhead around threading that means you want to break your program into as few pieces as possible. With Grand Central Dispatch, we say break your program into as many tiny pieces as you can conceive of."

Another difference with the Grand Central Dispatch approach is its centralisation. The operating system worries about managing all applications' blocks rather than each application providing its own oversight. That central view means the operating system decides which tasks get which resources, Apple said, and that the system overall can become more responsive even when it's busy.

There's a second mechanism in Snow Leopard that gives a new way for programmers tap into hardware power: OpenCL, or Open Computing Language. It lets computers use graphics chips not just to accelerate graphics but also some ordinary computations.

To use OpenCL, programmers write modules of code in a variation of the C programming language called OpenCL C. Snow Leopard translates that code on the fly into instructions the graphics chip can understand and transfers necessary data into the graphics system memory. Many tasks won't benefit, but OpenCL is good for videogame physics simulation or artificial intelligence algorithms, technical computing chores, and multimedia operations.