Desktop multiprocessing: Not so fast

Not every application can be reprogrammed for multicore architectures, and some bottlenecks will always remain. Here's why.

1 2 3 4 5 Page 4
Page 4 of 5


"What we'd all like is a magic compiler that takes yesterday's source code and spreads it across multiple cores, and that is just not happening," Turley says. "There are C compilers that make a modest dent, but a lot of research indicates that C will never take you very far since the fundamental problem is C itself -- it is inherently serial. There is no easy way to program in parallel; it's like writing poetry in Klingon."

Turley says that the world does not need yet another programming language. "Any third-year student worth his salt has invented one, but the trouble is getting people to adopt it -- no one wants to learn a new language." Since there are so many alternative approaches, "no one wants to commit," he says. If some authority would declare for one approach people would rally around it, but in the meantime there is widespread confusion and competing claims. "We may have to wait for the current generation of programmers to die off and be replaced by programmers brought up on a new paradigm," Turley laments.

The easiest way to add parallelism is to call code that is already parallelized, from a library, says Williams at Adobe. The next easiest is to use bottleneck routines, or separate little routines that only know about specific pixels. "That is the way we did it for a long time," he says. A third way is to write a parallel version of a complicated algorithm. But "that can easily take twice as much work [as writing a non-parallel version]. We're not talking about 10% more work here."

A fourth approach is functional parallelism, "where you let the user do different things simultaneously, such as getting thumbnail images while changing meta-images," Williams explains. "Photoshop was written before system software supported that, so we don't do a lot of that. Modern operating system facilities let you do functional threading without a huge amount of effort -- maybe 50% more -- but converting a large algorithm written before such stuff was available is a big effort," he says.

What is needed is not more code but different code -- and a different way to organize the application, adds Smith at Microsoft. "You must understand parallelism and that is not always obvious."

A first step is to minimize the use of variables. "Variables are artifacts of sequential execution," Smith says. "If it is always true that A+B=C, what if someone gets in the middle of that and adds something to B so that the equation no longer holds true? You must have a consistent state where that is prevented." Traditionally this prevention is done by locking the variables, but he advocates the use of transactional memory, which does much the same thing automatically by isolating the variables from other code that is running at the same time.

1 2 3 4 5 Page 4
Page 4 of 5
7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon