|
Wednesday, November 01, 2006 The Trouble with Multi-Core ComputersAdding more cores to a computer makes it faster, but it also makes it tricky to program. How will computer scientists cope? By Kate Greene
Today's top-of-the-line computers have dual-core processors: two computing units that can handle separate tasks at the same time. And by next year, major chip makers Intel and AMD will have rolled out quad-core systems. Although multiple processors are theoretically faster than a single core, writing software that takes advantage of many processors--a task called parallel programming--is extremely difficult. Recent research from MIT, however, could make parallel programming easier, ultimately helping to keep personal-computing performance on track. The researchers are proposing a new computing framework that combines specialized software instructions and modifications to multi-core hardware that could allow programmers to write software without having to deal with some tedious parallel-programming details. Historically, writing software for multi-core systems has been the job of experts in the supercomputing world. But with the coming age of personal supercomputers, average programmers also need to be able to write software with multiple cores in mind. "That's a scary thing," says Krste Asanovic, professor of electrical engineering and computer science at MIT, "because most have never done that, and it's quite difficult to do." Asanovic and his colleagues are tackling one of the main challenges that programmers face when they try to write software that will run efficiently on multi-core systems: coordinating multiple tasks that run on separate cores in a way that doesn't cause the system to crash. When an application such as Microsoft Outlook or a video player is parallelized, certain tasks are divvied up among the processors. But often, these separate tasks need to dip into a shared memory cache to access data. When one transaction is accessing memory and another transaction needs to access the same part of the memory, and proper safeguards aren't put in place, a system can crash. This can be compared to a couple with a shared checking account with limited funds writing checks simultaneously and inadvertently overdrawing from the account. Standard parallel programming requires a programmer to anticipate these simultaneous activities and make sure that once a certain activity begins to access memory, it "locks" out other activities so they wait until the transaction is completed. When implemented correctly, the locks speed up parallel systems, but putting them into practice is complicated, says Jim Larus, research area manager at Microsoft. For instance, he explains, two different applications could acquire locks at the same time, which forces them to wait for each other. Without some third party coming in to break up the "deadlock," Larus says, the applications would stay frozen.
|
 |
|
||||||||||||||||||||
| |||||||||||||||||||||
Audio »
Share »
Digg this
Add to del.icio.us
Add to Reddit
Add to Facebook
Slashdot It!
Stumble It!
Add to Newsvine
Add to Connotea
Add to CiteUlike
Add to Furl
Googlize this
Add to Rojo
Add to MyWeb
Favorite
Print
E-mail
Comments
buckminster on 11/01/2006 at 10:33 AM
2
R/T applications typically requires that the system respond to external events within a fixed time period. Code already executing must be interrupted in order to deal with the real-time event. This simultaneous execution of multiple interacting tasks could be separate programs, or implemented as a set of light weight processes running within a single program. These tasks may also be executing on a single processor, or several processors working together.
R/T software typically has "critical sections" where access to common data structures must be serialized in the same manner as the developers working on multi-core computer. Concurrent programming is another class of software that must provide the same type of data access constraints.
Most solutions to the problem of concurrent access are derived from the pioneer efforts of Edsger Dijkstra. Semaphores, mutual exclusion variables (mutex), and a dozen other solutions providing a concurrent access mechanism have been in use for decades now.
The developers writing software targeting multi-core computers are fortunate to have this rich heritage of well tested solutions to the problems they face.
ebernabei on 11/02/2006 at 2:51 PM
1
We all agree it _could_ be done with yesterday's methodologies and frameworks, but at what cost? At what efficiency? By whom?
Also, your use case is very limited. What about data processing of 100's of Gigs of information? It's not an R/T problem, but certainly most COBOL, Java and C++ apps today wouldn't use more than 1/80th of the aforementioned multicore CPU power.
Hence the advent of J2EE and .NET frameworks for web apps scalability (many, small, transaction requests), but what about larger batch or near-realtime data-intensive applications?
We've got work to do.
neilrieck on 11/03/2006 at 6:25 AM
4
dlonghurst on 11/09/2006 at 3:26 PM
1
More and more often, programmers kick off threads to keep dialogs awake but never look at the implications. Thus, unintentional parallelism will probably be as much a problem in the next few years as BSTR's seem to be to COM newbies.
If I can venture a guess, the common OS is not likely to automatically kick in 2 cores for 1 program automatically -- outside of OS requests of course. Valuable as multiple cores can be, the benefit will most likely be reaped by the OS running different programs on each core rather than programmers taking the time to change their thinking. The machine will be responsive in addition to your program running as fast as it did yesterday.