Parallel computation: Difference between revisions
imported>Yuval Langer m (Bolding parallel computation in the begining of the article) |
imported>Niek Sanders m (SIMD example.) |
||
Line 19: | Line 19: | ||
2004. 27 Mar. 2007 <http://www.ddj.com/dept/cpp/184401865>.</ref> | 2004. 27 Mar. 2007 <http://www.ddj.com/dept/cpp/184401865>.</ref> | ||
* SIMD, MIMD instructions | * SIMD, MIMD instructions | ||
*# SIMD: Intel SSE3 instructions. Operate on 128-bit register which can hold 4-floats/2-doubles/etc. | |||
* Memory Interlock | * Memory Interlock | ||
*# Dekker's Algorithm <ref name=Dijkstra68>E.W. Dijkstra, Cooperating Sequential Processes (Techniche Hogeschool, Eindhoven, 1965). Reprinted in: F. Genuys (ed.), Programming Languages, Academic Press, 1968, 43--112.</ref> | *# Dekker's Algorithm <ref name=Dijkstra68>E.W. Dijkstra, Cooperating Sequential Processes (Techniche Hogeschool, Eindhoven, 1965). Reprinted in: F. Genuys (ed.), Programming Languages, Academic Press, 1968, 43--112.</ref> |
Revision as of 15:35, 16 April 2007
In parallel computation, multiple code (programming) instructions are executed at the same time. This parallelism can range from coarse to fine grained. An example of coarse parallelism is a ray tracer rendering a separate output pixel on each available CPU. An example of fine grained parallelism is found in multiplying an n-dimensional vector by a scalar. The vector is cut up and a chunk is distributed to each CPU, the multiplication is done on each chunk, and the result is reassembled.
These examples illustrate key limitations to parallel computing. First, there is the overhead of distributing and reassembling the computation. Second, there is the challenge of developing parallel algorithms. In the ideal case, such as in a ray tracer, elements of the problem (pixels to be rendered) do not depend on one another. That is, the computing one output pixel does not require information or affect any of the other output pixels. These uncoupled problems are referred to as Embarrassingly Parallel. Many problems do not fit in to this category, an example being the classic N-body.
Parallel algorithms and programs are significantly more difficult to write and debug. However, as multicore processors (many armed with SIMD commands) become increasingly common, parallel computation is finding its way in to more mass-consumer code [1]. (e.g. mp3 encoders using SIMD, photoshop multiprocessor support, etc).
Note that it is generally possible to run parallel code on a single processor. Multiple processors are simulated through context switching. When running on a single processor, parallel algorithms typically have worse performance than their serial analogues, mainly because of the overhead of the distribution/communication logic.
Problem Domain
Algorithms
Hardware
Typically the CPU must offer some atomic operations to allow for parallel code to be written. There is also a famous algorithm which takes advantage of memory interlock to allow for mutual exclusion.
- Test and Set (TAS)
- Compare and Swap (for Lockfree programming) [2]
- SIMD, MIMD instructions
- SIMD: Intel SSE3 instructions. Operate on 128-bit register which can hold 4-floats/2-doubles/etc.
- Memory Interlock
- Dekker's Algorithm [3]
Software
Low Level Primitives
- Semaphores
- Mutexes
- Monitors
- Special purpose languages for parallel computation (Occam)
- Pure functional languages
Compiler Support
- Auto vectorizing compilers
- Speciality languages for Parallel programming
Library Support
- OpenMP
- Open standard
- Can be used to implement fine grained parallelism
- Built in support in many commercial compilers (Intel C/C++/FORTRAN, GCCv4, Sun CC)
- Uses meta-code to annotate which parts of a C or FORTRAN program can be parallelized.
- In C this is accomplished through the use of preprocessor pragmas
- Pragmas indicate things like "execute loop in parallel" or this variable has no dependency between iterations.
- Message Passing Interface (MPI)
- Well suited to cluster computing.
- Major library is LAM/MPI. Some vendors (e.g. Sun) also roll their own, optimized versions.
Research
A major recent development has been the advancement of Lock-Free programing. This allows for the development of thread-safe code with out the use of locking mechanisms such as semaphores [2]. While implementing correct lock-free algorithms is considered extremely difficult, they show significant performance advantage over their traditional counterparts. For example, the lock-free dynamic memory allocator implemented in [4] shows up to a 331% speedup over a traditional lock-based allocator when operating on 16 processors under maximum contention. This lock-free allocator also offers better scalability and latency than traditional allocators.
Related Topics
Citations
- ↑ Sutter, Herb. "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software." Dr. Dobb's Journal Mar. 2005. <http://www.gotw.ca/publications/concurrency-ddj.htm>.
- ↑ 2.0 2.1 Alexandrescu, Andrei. "Lock-Free Data Structures." C/C++ Users Journal 1 Sept. 2004. 27 Mar. 2007 <http://www.ddj.com/dept/cpp/184401865>.
- ↑ E.W. Dijkstra, Cooperating Sequential Processes (Techniche Hogeschool, Eindhoven, 1965). Reprinted in: F. Genuys (ed.), Programming Languages, Academic Press, 1968, 43--112.
- ↑ Michael, M. M. 2004. "Scalable lock-free dynamic memory allocation". SIGPLAN Not. 39, 6 (Jun. 2004), 35-46. DOI= http://doi.acm.org/10.1145/996893.996848