What's so scary about parallel programming? To start, it's been relegated to specialists in the high-performance computing (HPC) world who write software that solves specific problems that run on machines with thousands and millions of cores. The software can create climate-change models or predict the folding of proteins, but it is written for a single laborious task, not for the whims of consumers who want to talk to a computer, watch high-definition video, and keep tabs on their ageing parents halfway across the country.

Specifically, parallel programs must be written so that tasks can be appropriately shared among processors. This is difficult because not all applications naturally have components that can be separated; sometimes when they are separated, tasks are completed at different times and create bottlenecks. In addition, there are complications with shared resources: if an application needs to access data in memory that's shared by tens or hundreds of other cores, the program could slow down or freeze. Moreover, debugging parallel programs can be a nightmare because often, a mistake is hard to duplicate, making the source of the problem difficult to find.

But even with all the challenges, there is hope, says Shalf. HPC researchers have developed portfolios of parallel algorithms that could be useful for consumer parallel programs. In addition, there are already massively multicore products on the market, and they are providing clues as to the best approaches from an architecture standpoint as well as from a programming standpoint. For instance, graphics company NVIDIA just released a commercial chip with 128 cores, designed to render graphics for applications such as video games. Many of the cores are general-purpose, meaning they can be programmed to do many different graphics-oriented tasks. The alternative is for the cores to have instructions hard-wired into the chip.

In addition, Intel, AMD, and others are collaborating with academic researchers to try to create a parallel-programming framework that can be agreed upon. One approach that looks promising is called transactional memory, says Krste Asanović, professor of computer science at MIT. (See "The Trouble with Multicore Computers.") Using transactional memory, a combination of chip architecture and code, programmers will be allowed to think more sequentially, as they do when they program single-core systems, and let the system provide the parallelism. Asanović says that programmers write instructions that start and end in a linear fashion, "but behind the scenes they run in parallel." This approach requires cooperation from hardware vendors as well as software engineers because the hardware and software must work together. "The two communities are talking," Asanović says, "but there's no consensus on what it's going to look like." He adds that transactional memory will most likely be one of a combination of approaches that could help make programming in parallel easier.

Without a consensus on how to proceed with multicore technology, however, the consumer computing industry might find itself at a standstill in about five years, says Shalf. But he's optimistic because the field of parallel computing has been injected with a new sense of urgency with the emergence of dual- and quad-core products. "In academia, we can disagree for years," he says, "but industry has a way, with its economic imperative, to settle on a solution pretty quick."