(Page 2 of 2)
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.
IBM's combination of hardware and software crunches financial data at an unprecedented rate.
Manufacturing in the United States is in trouble. That's bad news not just for the country's economy but for the future of innovation.
This document is part of the “How-To Guide for Most Common Measurements” centralized resource portal. This tutorial provides a detailed guide for measurement and device considerations to take temperature measurements using thermocouples. Get an introduction to thermocouples, which are inexpensive sensing devices widely used with PC-based data acquisition systems. Also review some specific thermocouple examples and learn how thermocouples work and ways to integrate them into a data acquisition measurement system.
View full PDF >
Listen to story > 
On Twitter
Become a Fan on Facebook
Subscribe to the Feed
buckminster
2 Comments
Not really a new problem...
The issues facing apps developers on multi-core computers have been a very familiar problem to "real-time" software developers for decades.
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.
Reply
ebernabei
1 Comment
Re: Not really a new problem...
And so the universe of developers that can truly harness 80-core, single-chip systems (if you believe Intel's claims for what's to come in 2010) will be the world of R/T programmers. Wow... small world.
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.
Reply
neilrieck
67 Comments
Re: Not really a new problem...
Might be a new problem for PC technology but not new for minicomputers. A cool little module in OpenVMS (since 1977) called the Distributed Lock Manager (DLM) works in VMS clusters as well as Symetric Multi Processing (SMP) implementations. Multi-core PCs today remind me of SMP technology 15 years ago so why not see how those engineers solved those problems? No need to reinvent the wheel. Now getting multiple threads from the same application to work across different cores is a different problem.
Reply
dlonghurst
1 Comment
Re: Not really a new problem...
I have quite a few years of dealing with hardware interrupted pre-emptive software. This is not a new problem when looked at specifically in terms of real time programming. However, the new problem is releasing multiple treads in either pre-emptive or parallel execution from programmers without the RT black magic in their bag of tricks.
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.
Reply