Most Read Latest News Blog Resources

Design Difficulty: From Unicore To Dual-Core to Quad-Core and Beyond




December 15, 2006 — 
Which is more difficult: Moving from unicore to dual-core or from dual-core to quad-core and beyond?

Michael Christofferson, director of product management at Enea, said the move from unicore is a larger step because Enea has had to take several RTOS components and make them Symmetric Multiprocessing-aware.

“Once you’ve gone to multicore, you’ve solved the logical problem,” he said. “If you solve concurrency and load balancing, the move from unicores to dual cores is minimal from an RTOS perspective and no issue from an application perspective.”

Geoff Lowney, fellow in the digital enterprise group and director of compiler and architecture advanced development at Intel, also thinks the move to dual cores is more difficult because designers have to consider parallel processing as opposed to serial processing from a conceptual point of view.

“Once you have developed a parallel program, it will scale easily,” he said.

Robert Craig, a software manager at QNX Software Systems, said the move to dual cores and beyond is more difficult because scaling becomes an issue.

“If you’re using two different operating systems, the applications and binaries differ so scaling becomes difficult,” he said. “If you use the same OS, you have the same binaries but it’s difficult to scale because the OSes are running independently but don’t know what the other cores are doing.”

If you stop one core and start another, state problems occur.

“There’s a large codebase that may be difficult to debug and rearchitect to get legacy applications up and running,” said Craig. “People who are happy with uniprocessors are scared by a concurrent model. They need to learn about parallelism.”

The robustness of an implementation can also be affected by the applied algorithm such as expected time of execution, memory consumption, core CPU utilization and the availability of each core to new applications, and thread processing (which consume more bandwidth in a multicore environment).

From a software perspective, core utilization needs to be monitored, but designers also have to understand where the loads are.

“We really only have software measures for [monitoring cores and], it doesn’t scale linearly,” said Enea’s Christofferson. “It will take more than 8 times the code execution to go from two to 16 cores because there’s a lot involved.”

Eventually it is possible to reach a break-even point where the amount of analysis consumes so much bandwidth that it’s difficult to get more performance out of additional cores, he said. One solution is to have hardware-assisted algorithms, he suggested—cores that have built-in features that understand core utilization so decisions can scale to the number of cores while consuming minimal overhead.


Share this link: http://www.sdtimes.com/link/29911
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading



 
 
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

4/12/2010 to 4/14/2010
Las Vegas
Penton Media

4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media

4/19/2010
New York City
Flagg Management

4/25/2010 to 4/28/2010
Overland Park, Kans.
IIUG