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

The interesting bit is that, using the testing workloads they came up with, they were able to find that Vista and 7 were almost exactly the same, barring some tweaks, and very different from XP under the hood. Our analogy would be that Windows XP is an orange, and Vista and 7 are a banana and a ripe banana, respectively.

Another point Infoworld brought up is that both Vista and 7 are actually more optimized for multicore performance than XP, naturally.

Taken to its logical conclusion — and disregarding for the moment external factors, like bus speeds, I/O contention, and memory latency — Vista would ultimately overtake XP when the core count reaches between 32 and 64.

And in Windows 7, they suggest that it will overtake Windows XP at around 16 or 24 cores. So although it may be slower now, in a few years, when you have 16 or 24 cores, you're going to be thankful for Microsoft for their work. But until then, Ballmer can expect lots of angry fist shaking. [Infoworld via Slashdot]

Of course, the reality of parallel computing is much more complex than the MythBusters are making it seem here, but as with many of the experiments on their TV show, the sheer ridiculousness of this demonstration makes its questionable veracity completely, totally, seriously excusable. Now that they've built this thing, the MythBusters have a clear and undeniable responsibility to turn it on a human and put the results on TV. Thanks in advance, guys. [TGDaily via CrunchGear]

This massively-parallel architecture is ideally suited to gaming systems, of course, but Intel plans on extending its usefulness into the handheld and even supercomputing domains. Larrabee's chief designer puts the new chip architecture "on the level of the 432 or the Itanium.” It'll be competing against next-gen chips from Nvidia and ATI, which will have between 256 and 800 cores, so Larrabee is relying on its "high speed ring" which interconnects cores more efficiently than current designs. Should be available in late 2009 or early 2010. Interesting stuff. [NYTimes]

1.

The way the processor industry is going is to add more and more cores, but nobody knows how to program those things. I mean, two, yeah; four, not really; eight, forget it.

Jobs claims that Apple's made a "breakthrough" in parallel-programming called Grand Central, which he alluded to in his keynote yesterday. He didn't, however, go into details about how it works and why it's going to revolutionize dividing up tasks into multiple processors in ways that other operating systems haven't yet.

What's also interesting is the ability to bring the GPU (your graphics card) into the processing role to help out your CPU. Apple's calling this newly proposed standard OpenCL (Open Compute Library).

2.

Basically it lets you use graphics processors to do computation. It’s way beyond what Nvidia or anyone else has, and it’s really simple.

It's vaguely similar to the way that Photoshop CS 4 will use your graphics card to help process image manipulation and help out in rendering 3D models as well.

Will there be more features like Time Machine? Not according to Jobs.
3.

“We’ve added over a thousand features to Mac OS X in the last five years,” he said Monday in an interview after his presentation. “We’re going to hit the pause button on new features.”

Seems to us that Snow Leopard won't be heavy on the features, but it will increase processing speeds for people who are heavy on the processing in their daily computing and have more than just a few cores—a place we're all heading to in the next few years. [NYT]

It might be time to change our way of thinking about processor speed. Now Intel is hinting at processors with 32 cores available by the end of this decade. Sure, the company predicted 20GHz chips by 2010 a few years ago, but now instead of higher gigahertz numbers, they're talking multiple cores that will result in a processor that will be 15 times faster than today's quickest chips.

Intel has assigned the pet name "Keifer" to the many-core processor project in general and "Gulftown" specifically to its 32-core processor that will be manufactured using a 32nm process, and it will include eight processing nodes, each with four cores. The jaw-dropper is that each one of these cores will be running at a paltry 2GHz, but since there are 32 of them, they'll leave today's processors in the dust. That is, unless Intel thinks of something else between now and then, which wouldn't be all that unusual. – Charlie White

Intel aims for 32 cores by 2010 [TG Daily]