The Leading Source for Global News and Information Covering the Ecosystem of High Productivity Computing
April 06, 2007
Compilers and More: What To Do With All Those Cores?
1 | 2 | 3 All »
I just returned from two small conferences, CGO (Code Generation and Optimization, http://www.cgo.org/) and PPoPP (Principles and Practice of Parallel Programming, http://www.ppopp.org/). One of the key themes in both conferences, perhaps the dominating theme, was that multicore chips are here, are mainstream, and we'd better figure out how to use them.
One of the PPoPP attendees, Prof. Rudolf Eigenmann (Purdue Univ.) issued an indictment, saying that we in the parallel programming research community should be ashamed of ourselves. Single-processor systems have run out of steam, something the parallel programming community has been predicting since I was a college student. Now is the time to step up and reap the benefits of all our past work. We've had 30 years to study this problem and come up with a solution, but what's the end result? Surprise! We still have no well-accepted method to generate parallel applications.
We had a similar discussion at one of the workshops before CGO, where someone said that the programming problem would finally get solved because "now we're motivated!" This implies either that the past thirty years of investigation was being done by the wrong people, or that perhaps now with more people looking at the problem, someone will randomly stumble on a good solution. Science at its best?
Dr. Andrew Chien (Intel), one of the PPoPP keynote speakers, took issue with Eigenmann's criticism. Chien said that in fact we've had a great deal of success in parallel programming: just look at all the massively parallel systems and the applications that run on them. However, halfway through his talk was the slide "Wanted: Breakthrough Innovations in Parallel Programming." I asked how he could claim past success, then state that breakthrough innovations are needed; it sounded like a typical manager: "good job, now get back to work." He replied that in the past, parallel programming meant high performance. Now, parallel programming means spreadsheets, games, email, and applications on your laptop. It's a different target environment, with a different class of programmer, and different expectations.
So parallel programming is hard. Hey, sequential programming is hard too. Adding parallelism just makes it harder. Two of the major problems are expressing the parallelism and synchronizing or communicating between the parallel threads or activities.
An approach to the synchronization problem that is gaining lots of traction is transactional memory, or TM. This takes a page from the successful database community, which has long had to deal with many processes simultaneously accessing and modifying a shared database. Rather than letting a process lock the database, the process executes a transaction; the transaction may involve adding, removing, or modifying relations in the database. While in the middle of a transaction, no other process can see the modifications; at the end, the process commits the results. The database then atomically exposes all the updates to the other processes. In particular, this lets multiple processes modify disjoint parts of the database in parallel without conflict. If two processes try to update the same data at the same time, the first commit will succeed, and the second will fail. The application then has to restart its transaction from the start, since it may have made some decisions based on values that are now stale.
Moving transactions to the parallel programming world means rather than updating shared data in a critical section, the model is to enter a transaction, perform the updates, then commit the changes. The implementation must buffer the modifications until the commit, then atomically commit all the modifications at once. As in a database, if some other parallel thread had made changes to the same shared data, the commit will fail, and the transaction must restart and retry. The expected behavior is that most transactions will succeed, so the retry overhead is quite low.
However, it's still open as to how to implement the transaction buffering and commit. Modified caches could be used to buffer stores, unless you run out of associativity on the cache line. A separate transactional store queue could be designed, but the size of the queue would limit the size of the transaction.
There are other problems as well. Imagine two transactions, A and B, reading and modifying the same shared data. Suppose transaction B finishes and commits while A is still working. If transaction A then reads some data that was modified by B, A's commit is likely to fail (in fact, may be guaranteed to fail), since some of the data it read was before B's commit and some was read after. In fact, the inconsistency may cause A to generate a fault (suppose B allocated or freed a pointer), or loop infinitely; one speaker termed A a "zombie transaction," the walking dead. It can be important to detect and kill zombies before they get to the commit state, to avoid spurious faults.
In managed software environments (think Java or C#), these problems can be handled in software, and transactions are likely to be successful there. However, it remains unclear how long it will be before transactions can migrate into HPC.
Page: 1 of 31 | 2 | 3 All »
Article Tools
Share Options
(Digg, Technorati, more)
Subscribe
Sponsored Links
New Paper: Parallel Computing Without Parallel Programming
Learn how domain experts can run VHLL programs like MATLAB® on a variety of high-performance platforms without low-level reprogramming and how to work with the largest datasets and complex algorithms without sacrificing ease of use or reducing productivity.
RSS Feeds
Feeds by Topic
- Applications
- Developer Tools
- Interconnects
- Middleware
- Networks
- Processors
- Storage
- Systems
- Visualization
Feeds by Industry
Feeds by Content Type
Top Headlines
3D Seismic Data: Taking a Smarter Approach to Interpretation
Jul 09 | Engineer Live | The demand for computational tools to underpin the 3D seismic interpretation process has never been more apparent. Read more...
Engineering Unemployment Soared in 2Q to 8.6%
Jul 08 | EE Times | Unemployment for U.S. engineers has reached record levels, according to government figures. Read more...
Gartner Adjusts 2009 IT Spend Downward Again
Jul 08 | Network World | Global spending for 2009 projected to drop 6 percent, for a total of $3.2 trillion. Read more...
Concurrent and Parallel Are Not The Same
Jul 08 | Linux Magazine | Portability or efficiency? Neither is guaranteed when writing explicit parallel code. Read more...
800 TFLOP Real-Time Ray Tracing GPU Unveiled, Not for Gamers
Jul 07 | Ars Technica | Japanese company builds custom ASIC to accelerate real-time ray traced rendering for the auto industry. Read more...
Featured Whitepapers
Parallel Computing Without Parallel Programming
Jul 10 | | Engineers, scientists, and other domain experts depend on the productivity enabled by very high-level language (VHLL) tools like MATLAB® and Python. However, as datasets grow larger and programs get more sophisticated, ordinary desktop computers can no longer keep up. The paper explores how to run VHLL programs on high-performance platforms without low-level reprogramming. Work with large datasets and complex algorithms without sacrificing ease of use or reducing productivity.
Building High Performance Computing in a Green and Modular Solution Building Block
Apr 14 | | Many HPC IT departments are feeling the rising pressure to deliver more capacity computing and performance while trying to reduce the total cost of ownership. This white paper discusses how an environmentally-friendly and open-standards HPC building block based computing system using flexible interconnect options helps address capacity computing needs.
Multimedia
Webcast: Dell Expands HPC Access and Adoption with Intel Cluster Ready Program
Source: Addison Snell, GM/VP, Tabor Research; sponsored by Dell
Many organizations that could benefit from the use of HPC clusters find that it is complicated to get the systems up and running because of limited IT resources or the complexities of the clusters themselves. Learn how the Intel Cluster Ready program, for which Dell was an original partner, seeks to address this challenge for entry level and mid-range HPC users.
Video White Paper: Architecting a Better Network Storage Solution
BlueArc's Titan architecture represents an evolutionary step in file servers by creating a hardware-based file system that can scale bandwidth, IOPS, and overall data capacity well beyond conventional software-based devices. With its ability to virtualize a massive storage pool of up to four usable petabytes of tiered storage, Titan can scale with growing data requirements, offering a competitive advantage for businesses, researchers, or other enterprises seeking to better manage data growth while still ensuring optimal performance.
Webcast: HPC Development Solutions: Sun Studio & Sun HPC ClusterTools
Sun Studio Compilers and Tools and Sun HPC ClusterTools allow you to create high performance parallel applications for OpenSolaris, Solaris and Linux. Sun Studio Express 11/08 includes MPI performance analysis capabilities and full OpenMP 3.0 compiler support. Learn about all this and the latest in Sun HPC ClusterTools 8.1.
Newsletters
Stay informed! Subscribe to HPCwire email Newsletters.
HPC Job Bank
-
HPC Systems Administrator
McGill University -
High Performance Computing Systems Administrator
Idaho National Laboratory -
Solution Engineer- HPC
Dell Inc -
Parallel Programmer
Cardiff University -
Principal Software Research Engineer
Indiana University -
Post Doctoral Researcher - Exascale Stream Computing
IBM - Visit the HPCwire Job Bank
Featured Events
-
July 13-16, 2009
WORLDCOMP'09
Las Vegas , NV
USA
-
August 24-28, 2009
Data Mining: Levels I, II, & III
Denver , CO
USA