Adding more cores to a computer makes it faster, but it also makes it tricky to program. How will computer scientists cope?
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.
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 > 
Our list of the 50 most innovative companies, including the following:
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