![](https://csdnimg.cn/release/download_crawler_static/8721951/bg14.jpg)
To protect the rights of the author(s) and publisher we inform you that this PDF is an uncorrected proof for internal business use only by the author(s), editor(s),
reviewer(s), Elsevier and typesetter diacriTech. It is not allowed to publish this proof online or in print. This proof copy is the copyright property of the publisher
and is confidential until formal publication.
McCool — 04-pre-xix-xxii-9780124159938 — 2012/6/6 — 22:35 — Page xix — #1
Preface
All computers are now parallel computers, so we assert that all programmers are, or should be, parallel
programmers. With parallel programming now mainstream, it simply needs to be included in the def-
inition of “programming” and be part of the skill set of all software developers. Unfortunately, many
existing texts on parallel programming are overspecialized, with too much emphasis given to particular
programming models or particular computer architectures. At the other extreme, several existing texts
approach parallel computing as an abstract field of study and provide the reader with insufficient infor-
mation to actually write real applications. We saw a need for a text on parallel programming treating
the topic in a mainstream, pragmatic fashion, so that readers can immediately use it to write real appli-
cations, but at a level of abstraction that still spans multiple computer architectures and programming
models.
We feel that teaching parallel programming as an advanced topic, with serial programming as the
default basis, is not the best approach. Parallel programming should be taught from the beginning to
avoid over-learning of serial assumptions and thought patterns. Unfortunately, at present the default
teaching style is based on the serial code and algorithms. Serialization has become excessively woven
into our teaching, our programs, and even the tools of our trade: our programming languages. As a
result, for many programmers parallel programming seems more difficult than it should be. Many pro-
grams are serial not because it was natural to solve the problem serially, but because the programming
tools demanded it and the programmer was trained to think that way.
Despite the fact that computer hardware is naturally parallel, computer architects chose 40 years ago
to present a serial programming abstraction to programmers. Decades of work in computer architecture
have focused on maintaining the illusion of serial execution. Extensive efforts are made inside modern
processors to translate serial programs into a parallel form so they can execute efficiently using the
fine-grained parallel hardware inside the processor. Unfortunately, driven by the exponential increase
in the number of transistors provided by Moore’s Law, the need for parallelism is now so great that it
is no longer possible to maintain the serial illusion while continuing to scale performance. It is now
necessary for programmers to explicitly specify parallel algorithms if they want their performance to
scale. Parallelism is everywhere, and it is the path to performance on modern computer architectures.
Parallelism, even within a single desktop (or laptop!) computer, is available in many ways, including
vector (SIMD) instructions, multicore processors, GPUs, co-processors, and many-core processors.
Programming today needs to address all these forms of hardware parallelism in a manner that is abstract
enough to avoid limiting the implementation to a particular style of hardware.
We also saw a need for a structured approach to parallel programming. In this book, we explain and
illustrate essential strategies needed for writing efficient, scalable programs using a set of patterns. We
have found that patterns are highly effective both for learning this subject and for designing efficient,
structured, and maintainable programs. Using standard names for patterns is also a tremendous aid
to communication. Because vocabulary is important, we have assembled an extensive glossary. This
should help limit the need to read the book sequentially. The glossary also points to key discussions or
explanations of a term within a section of the book when appropriate.
To ensure that the book is useful in practice, we combine patterns with a set of examples showing
their use. Since there are many parallel programming models, the question arose: Which programming
model(s) should we use for examples? We wanted to show enough examples to allow the reader to write
xix