You’ve probably heard about this snow kitty operating system for Macintosh computers. What you might not’ve heard is exactly how it’s supposed to be unleashing the power of all those processor cores crammed inside your computer.
The heart of the matter is that the trick to actually utilizing the full power of multiple processors—or multiple cores within a processor, like the Core 2 Duo you’ve probably got in your computer if you bought in the last two years—is processing things in parallel. That is, doing lots of stuff side by side. After all, you’ve got 2, maybe 4 or even 8 processors at your disposal, so to use them as efficiently as possible, you want to pull a problem apart and throw a piece of it at each core, or at least send different problems to different cores. Sounds logical, right? Easy, even.
The rub is that writing software that can actually take advantage of all of that parallel processing at an application level isn’t easy, and without software built for it, all that power is wasted. In fact, cracking the nut of parallel processing is one the major movements in tech right now, since parallelism, while it’s been around forever, has been the domain of solving really big problems, not running Excel sheets on your laptop. It’s why, for instance, former Intel chair Craig Barrett told me at CES that Intel hires more software engineers than hardware engineers—to push the software paradigm shift that’s gotta happen.
A big part of the reason parallel programming is hard for programmers to wrestle with is simply most of them have never spent any time thinking about parallelism, says James Reinders, Intel’s Chief Software Evangelist, who’s spent decades working with parallel processing. In the single core world, more speed primarily came from a faster clock speed—all muscle. Multi-core is a different approach. Typically, the way a developer takes advantage of parallelism is by breaking their application down into threads, sub-tasks within a process that run simultaneously or in parallel. And processes are just instances of an application—the things you can see running on your machine by firing up the Task Manager in Windows, or Activity Monitor in OS X. On a multi-core system, different threads can be handled by different processors so multiple threads can be run at once. An app can a lot run faster if it was written to be multi-threaded.
One of the reasons parallel programming is tricky is that some kinds of processes are really hard to do in parallel—they have to be done sequentially. That is, one step in the program is dependent on the result from a previous step, so you can’t really run those steps in parallel. And developers tend to run into problems, like a race condition, where two processes try to do something with the same piece of data and the order of events gets screwed up, resulting in a crash.
Snow Leopard‘s Grand Central Dispatch promises to take a lot of the headache out of parallel programming by managing everything at the OS level, using a system of blocks and queues, so developers don’t even have to thread their apps in the traditional way. In the GCD system, a developer tags self-contained units of work as blocks, which are scheduled for execution and placed in a GCD queue. Queues are how GCD manages tasks running parallel and what order they run in, scheduling blocks to run when threads are free to run something.
Reinders says he’s “not convinced that parallel programming is harder, it’s just different.” Still, he’s a “big fan of what Apple’s doing with Grand Central Dispatch” because “they’ve made a very approachable, simple interface for developers to take advantage of the fact that Snow Leopard can run things in parallel and they’re encouraging apps to take advantage of that.”
How Snow Leopard handles parallelism with GCD is a little different than what Intel’s doing however—you might recall Intel just picked up RapidMind, a company that specializes in optimizing applications for parallelism. The difference between these two, at a broad level, represent two of the major approaches to parallelism—task parallelism, like GCD, or data parallelism, like RapidMind. Reinders explained it like this: If you had a million newspapers you want to cut clips out of, GCD would look at cutting from each newspaper as a task, whereas RapidMind’s approach would look at it as one cutting to be executed in a repetitive manner. For some applications, RapidMind’s approach will work better, and for some, GCD’s task-based approach will work better. In particular, Reinders says something like GCD works best when a developer can “figure out what the fairly separate things to do are and you don’t care where they run or in what order they run” within their app.
It’s also a bit different from Windows’ approach to parallelism, which is app oriented, rather than managing things at the OS level, so it essentially leaves everything up to the apps—apps have got to manage their own threads, make sure they’re not eating all of your resources. Which for now, isn’t much of a headache, but Reinders says that there is a “valid concern on Windows that a mixture of parallel apps won’t cooperate with each other as much,” so you could wind up with a situation where say, four apps try to use all 16 cores in your machine, when you’d rather they split up, with say one app using eight cores, another using four, and so on. GCD addresses that problem at the system level, so there’s more coordination between apps, which may make it slightly more responsive to the user, if it manages tasks correctly.
You might think that the whole parallelism thing is a bit overblown—I mean, who needs a multicore computer to run Microsoft Word, right? Well, even Word benefits from parallelism Reinders told me. For instance, when you spool off something to the printer and it doesn’t freeze, like it used to back in the day. Or spelling and grammar running as you type—it’s a separate thread that’s run in parallel. If it wasn’t, it’d make for a miserable-ass typing experience, or you’d just have to wait until you were totally finished with a document. There’s also the general march of software, since we love to have more features all the time: Reinders says his computer might be 100X faster than it was 15 years ago, but applications don’t run 100x faster—they’ve got new features that are constantly added on to make them more powerful or nicer to use. Stuff like pretty graphics, animation and font scaling. In the future, exploiting multiple cores through parallelism that might be stuff like eyeball tracking, or actually good speech recognition.
Reinders actually thinks that the opportunities for parallelism are limitless. “Not having an idea to use parallelism in some cases I sometimes refer to as a ‘lack of imagination,'” because someone simply hasn’t thought of it, the same way people back in the day thought computers for home use would be glorified electronic cookbooks—they lacked the imagination to predict things like the web. But as programmers move into parallelism, Reinders has “great expectations they’re going to imagine things the rest of us,” so we could see some amazing things come out of parallelism. But whether that’s next week or five years now, well, we’ll see.
[Back to our Complete Guide to Snow Leopard]
Still something you wanna know? Send questions about parallel processing, parallel lines or parallel universes to tips@gizmodo.com, with “Giz Explains” in the subject line.
Grand Central Terminal main concourse image from Wikimedia Commons
