"If you build it, they will come." And so we built them. Multiprocessor workstations, massively parallel supercomputers, a cluster in every department ... and they haven't come. Programmers haven't come to program these wonderful machines. Oh, a few programmers in love with the challenge have shown that most types of problems can be force-fit onto parallel computers, but general programmers, especially professional programmers who "have lives", ignore parallel computers. And they do so at their own peril. Parallel computers are going mainstream. Multithreaded microprocessors, multicore CPUs, multiprocessor PCs, clusters, parallel game consoles ... parallel computers are taking over the world of computing. The computer industry is ready to flood the market with hardware that will only run at full speed with parallel programs. But who will write these programs? This is an old problem. Even in the early 1980s, when the "killer micros" started their assault on traditional vector supercomputers, we worried endlessly about how to attract normal programmers. We tried everything we could think of: high-level hardware abstractions, implicitly parallel programming languages, parallel language extensions, and portable message-passing libraries. But after many years of hard work, the fact of the matter is that "they" didn't come. The overwhelming majority of programmers will not invest the effort to write parallel software. A common view is that you can't teach old programmers new tricks, so the problem will not be solved until the old programmers fade away and a new generation takes over. But we don't buy into that defeatist attitude. Programmers have shown a remarkable ability to adopt new software technologies over the years. Look at how many old Fortran programmers are now writing elegant Java programs with sophisticated object-oriented designs. The problem isn't with old programmers . The problem is with old parallel computing experts and the way they've tried to create a pool of capable parallel programmers. And that's where this book comes in. We want to capture the essence of how expert parallel programmers think about parallel algorithms and communicate that essential understanding in a way professional programmers can readily master. The technology we've adopted to accomplish this task is a pattern language . We made this choice not because we started the project as devotees of design patterns looking for a new field to conquer, but because patterns have been shown to work in ways that would be applicable in parallel programming. For example, patterns have been very effective in the field of object-oriented design. They have provided a common language experts can use to talk about the elements of design and have been extremely effective at helping programmers master object-oriented design. This book contains our pattern language for parallel programming. The book opens with a couple of chapters to introduce the key concepts in parallel computing. These chapters focus on the parallel computing concepts and jargon used in the pattern language as opposed to being an exhaustive introduction to the field. The pattern language itself is presented in four parts corresponding to thefour phases of creating a parallel program: Finding Concurrency . The programmer works in the problem domain to identify the available concurrency and expose it for use in the algorithm design. Algorithm Structure . The programmer works with high-level structures for organizing a parallel algorithm. Supporting Structures . We shift from algorithms to source code and consider how the parallel program will be organized and the techniques used to manage shared data. Implementation Mechanisms . The final step is to look at specific software constructs for implementing a parallel program. The patterns making up these four design spaces are tightly linked. You start at the top ( Finding Concurrency ), work through the patterns, and by the time you get to the bottom ( Implementation Mechanisms ), you will have a detailed design for your parallel program. If the goal is a parallel program, however, you need more than just a parallel algorithm. You also need a programming environment and a notation for expressing the concurrency within the program's source code. Programmers used to be confronted by a large and confusing array of parallel programming environments. Fortunately, over the years the parallel programming community has converged around three programming environments. OpenMP. A simple language extension to C, C++, or Fortran to write parallel programs for shared-memory computers. MPI. A message-passing library used on clusters and other distributed-memory computers. Java. An object-oriented programming language with language features supporting parallel programming on shared-memory computers and standard class libraries supporting distributed computing. Many readers will already be familiar with one or more of these programming notations, but for readers completely new to parallel computing, we've included a discussion of these programming environments in the appendixes. In closing, we have been working for many years on this pattern language. Presenting it as a book so people can start using it is an exciting development for us. But we don't see this as the end of this effort. We expect that others will have their own ideas about new and better patterns for parallel programming. We've assuredly missed some important features that really belong in this pattern language. We embrace change and look forward to engaging with the larger parallel computing community to iterate on this language. Over time, we'll update and improve the pattern language until it truly represents the consensus view of the parallel programming community. Then our real work will begin--using the pattern language to guide the creation of better parallel programming environments and helping people to use these technologies to write parallel software. We won't rest until the day sequential software is rare. 0321228111P08232004 Excerpted from Patterns for Parallel Programming by Timothy G. Mattson, Berna L. Massingill, Beverly A. Sanders All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.
