The Trouble with Multi-Core ComputersContinued from page 1
The MIT researchers get around this by using an approach called transactional memory, a research area that has exploded in the past five years, says Asanovic. Transactional memory coordinates software operations so that programmers don't have to write it into their programs. It actually allows numerous transactions to share the same memory at the same time. When a transaction is complete, the system verifies that other transactions haven't made changes in the memory that would hinder the outcome of the first transaction. If they have, then the transaction is re-executed until it succeeds. While transactional memory works in some cases, it's still not perfect, explains Asanovic. Most of the time the transactions are small, and the fixed size of the memory in the hardware can cope with them quickly. But, he says, once in a while transactions require more memory than the fixed amount that is available, and when this happens, the system crashes. Asanovic says that by adding a small backup memory cache to the hardware, and by adding software to recognize when the transactions are overflowing, the capacity of transactional memory can be increased, alleviating previous system failures. The method that the MIT researchers use relies on a combination of software and hardware to make transactional memory better, says Microsoft's Larus, and there have been numerous designs that rely on software or hardware to varying degrees. "It's not clear yet where the right line is" between using hardware and software to solve the problem, he says, but the researchers are tackling important unresolved issues in programming multi-core systems. Microsoft, AMD, Intel, and universities such as MIT and Stanford, among others, are all invested in making multi-core systems easier to program. In addition to improving transactional memory, researchers are exploring better ways of debugging parallel programs and also creating libraries of ready-made parallel operations so that programmers can plug chunks of code into software without having to work out the kinks each time. Currently, the dual-core systems aren't as affected by the lack of truly parallel programs as the coming quad-core systems will be, says Asanovic. For the most part, operating systems such as Windows and Mac OS X are able to effectively split up applications on a dual-core system. For instance, a virus scanner runs unobtrusively in the background on one core, while applications such as Microsoft Word or Firefox run on the other core, without their speed being hampered. But when it comes to 4, 8, or 16 cores, the applications themselves need to be modified to garner more performance. Asanovic says transactional memory won't be a silver bullet that makes it easier to program these systems, but he expects it to be a component of the future parallel-computing model. "It's one mechanism that appears to be useful," he says. |
E-mail
Audio »
Print
Favorite
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
Speeding Up Financial Analysis
04/15/2009
Download
Massachusetts Institute of Technology
Comments
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.
buckminster
11/01/2006
Posts:2
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.
ebernabei
11/02/2006
Posts:1
neilrieck
11/03/2006
Posts:19
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.
dlonghurst
11/09/2006
Posts:1