CSC/ECE 506 Spring 2012/3a kp: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
== Patterns of parallel programming == | == Patterns of parallel programming == | ||
Overview | |||
A design pattern is a description of a solution to a frequently occurring problem in some domain. The description makes it easy for the reader to quickly understand both the problem and the proposed solution. Because the pattern has a name, a collection of patterns provides a vocabulary with which to talk about these solutions. | |||
As an example – “Dense Linear Algebra” is a “Computational” design pattern for parallel programming. Under this pattern a computation is organized as a sequence of arithmetic expressions acting on dense arrays of data. The operations and data access patterns are well defined mathematically so data can be prefetched and CPUs execute close to their | |||
theoretically allowed peak performance. | |||
Parallel programming design patterns have been identified that are applicable at various levels of software development from high-level patterns that describe how an application is organized to midlevel patterns about specific classes of computations, and low level patterns describing specific execution strategies. Related to these classifications, there are also available “pattern languages” from several researchers, that guide the software developer through hierarchy of parallel programming design development. (http://www.cise.ufl.edu/research/ParallelPatterns http://parlab.eecs.berkeley.edu/wiki/patterns/patterns). | |||
In this article we first cover two/three of “pattern languages” for parallel programming in some detail. These are attempts to classify and we then dwell on commonalities of these approaches. Thereafter, we cover a broad range of parallel programming design patterns highlighting the commonalities and differences. | |||
It is important to appreciate that many design problems do not lend themselves to a top-down or bottom-up analysis. In many cases, the pathway through our patterns will be bounce around between layers with the designer working at whichever layer is most productive at a given time. | |||
http://en.wikipedia.org/wiki/File:Carillon,_Washington_Park.JPG | http://en.wikipedia.org/wiki/File:Carillon,_Washington_Park.JPG | ||
Revision as of 21:41, 9 February 2012
Patterns of parallel programming
Overview
A design pattern is a description of a solution to a frequently occurring problem in some domain. The description makes it easy for the reader to quickly understand both the problem and the proposed solution. Because the pattern has a name, a collection of patterns provides a vocabulary with which to talk about these solutions.
As an example – “Dense Linear Algebra” is a “Computational” design pattern for parallel programming. Under this pattern a computation is organized as a sequence of arithmetic expressions acting on dense arrays of data. The operations and data access patterns are well defined mathematically so data can be prefetched and CPUs execute close to their theoretically allowed peak performance.
Parallel programming design patterns have been identified that are applicable at various levels of software development from high-level patterns that describe how an application is organized to midlevel patterns about specific classes of computations, and low level patterns describing specific execution strategies. Related to these classifications, there are also available “pattern languages” from several researchers, that guide the software developer through hierarchy of parallel programming design development. (http://www.cise.ufl.edu/research/ParallelPatterns http://parlab.eecs.berkeley.edu/wiki/patterns/patterns).
In this article we first cover two/three of “pattern languages” for parallel programming in some detail. These are attempts to classify and we then dwell on commonalities of these approaches. Thereafter, we cover a broad range of parallel programming design patterns highlighting the commonalities and differences.
It is important to appreciate that many design problems do not lend themselves to a top-down or bottom-up analysis. In many cases, the pathway through our patterns will be bounce around between layers with the designer working at whichever layer is most productive at a given time.
http://en.wikipedia.org/wiki/File:Carillon,_Washington_Park.JPG
