Panel Confronts Multicore Pros And Cons

Panelists at the Multicore Expo generally agreed that multitasking and multiprocessing have bright futures, although they identified some challenges as well.

March 24, 2006

3 Min Read
NetworkComputing logo in a gray background | NetworkComputing

SANTA CLARA, Calif. — Panelists at the Multicore Expo here Wednesday (March 22) generally agreed that multitasking and multiprocessing have bright futures, although they identified some challenges as well. One of those challenges is the difficulty of programming next-generation multicore ICs.

Multithreading, said Michael Uhler, CTO of MIPS Technologies, provides an increase in performance without compromising power. He said the number of cores may be reduced as cores take on more capabilities, including multithreading. That's consistent with MIPS' position in February, when the company rolled out its MPS34K, a "virtual CPU" core that MIPS believes can forestall the need to move to multicore designs for some multimedia and network applications.

Heterogenous or asymmetric multiprocessing (AMP) multicore systems-on-chip (SoCs) are being built because they have lower bill of materials costs, Uhler said. "It wouldn't surprise me to see SMP [symmetric multiprocessing] on the host processor, with the system remaining AMP because of the BOM cost," he said.

John Goodacre, program manager for multiprocessing at ARM Ltd., also noted the difference between multiprocessing in SoCs and on the host processor. "There's a lot of momentum in looking at the host node as multicore," he said.

One of the challenges for AMP designs, he said, is the number of processors people are trying to work with. "The programmer is limited by the number of concepts he can hold in his head," Goodacre said. "Are you going to have 20 to 30 accelerators from different vendors? No — the licensing department isn't going to like that very well."A key part of the problem is the software developer, Goodacre said. But the developer doesn't need a whole new set of APIs and compilers. The key to success, Goodacre said, is to maintain software compatibility, so that tasks run as they would in a uniprocessor system.

Rick Hetherington, distinguished engineer at Sun Microsystems and chief architect of the Niagara processor, noted a number of advantages of chip multi-threading (CMT). These include the best performance throughput for a given die size, a relative insensitivity to memory latency, no need for level two caches, and the highest available throughput per watt of power consumption.

But there are downsides, he noted. For one thing, floorplanning is a challenge. Further, he noted, CMTs are not general-purpose processors and are not ready for desktop applications. And Sun's Niagara implementation, which includes 8 cores with 4 threads each, requires the operating system to scale to 32 threads and beyond.

Robert Craig, senior software engineer at QNX, noted that the performance gains from multitasking are highly application dependent. Some applications might gain 50 percent, while others gain less than 10 percent. Multiprocessing, on the other hand, gives a better performance gain and is less dependent on the application, he said.

"With multitasking software, you have to parallelize the application, and understand what the application is doing in order to get maximum performance gain," Craig noted. "There's a lot of fear associated with concurrency in the embedded space. There's an education people have to go through with multiple processors to understand how to get performance out of them.""To use multicore, you really have to use multiple threads," said Tomas Evensen, CTO at Wind River Systems. "If you know how to do it, it's not bad. But the first time you do it there are lots of ways to shoot yourself in the foot. The bugs you introduce with multithreading are so much harder to find."

Software development changes in multicore environments, Evensen noted. For example, setting a task to the highest priority might not work. Further, in debugging, stopping the processor may not work, because others will simply continue. What's needed, he said, is "dynamic debugging" while the system is running.

Until recently, noted Dileep Kulkarni, strategic planning manager at Intel, multithreading was limited to a small set of applications. But now, he said, the number of applications, developers and users is "scaling enormously." Multithreading architectures will have millions of users, not thousands, he said.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights