|
Despite rapid advances in parallel hardware performance, the full potential of processing power is not being
exploited in the community for one clear reason: difficulty of designing parallel software. Identifying tasks,
designing parallel algorithm, and managing the balanced load among the processing units has been a
daunting task for novice programmers, and even the experienced programmers are often trapped with design
decisions that underachieve in potential peak performance.
Over the last decade there have been several approaches in identifying common patterns that are repeatedly
used in parallel software design process. Documentation of these “design patterns” helps the
programmers by providing:
- definition
- solution
- guidelines for common parallelization problems
In practice, however, the parallel design patterns identified thus far [over the last two decades!] contribute little—if
none at all—to development of non-trivial parallel software. In short, the parallel design patterns are too trivial
and fail to give detailed guidelines for specific parameters that can affect the performance of wide range of
complex problem requirements.
By experience in the community, it is coming to a consensus that there is only limited
number of patterns:
- Pipeline
- Master and Slave
- Divide and Conquer
- Geometric Decomposition
- Replicable
- Repository
So far the community efforts were focused on discovering more design patterns, but new patterns vary a little and
fall into range that is not far from one of the patterns mentioned above. The source of ineffectiveness of these
patterns, in fact, does not come from its lack of variety, but it comes from inflexibility of how existing patterns are
presented.
Literature:
Separation of Concerns in Parallel Patterns / Resources on Parallel Patterns
(PDF,
DOC)
Source: Resources on Parallel Patterns /
Pattern Collection / Separation of Concerns in Parallel Patterns
|
