1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
|
<?xml version="1.0" encoding="iso-8859-1"?>
<sect1 id="concurrent-and-parallel">
<title>Concurrent and Parallel Haskell</title>
<para>
<indexterm><primary>Concurrent Haskell</primary></indexterm>
<indexterm><primary>Parallel Haskell</primary></indexterm>
Concurrent and Parallel Haskell are Glasgow extensions to Haskell
which let you structure your program as a group of independent
`threads'.
</para>
<para>
Concurrent and Parallel Haskell have very different purposes.
</para>
<para>
Concurrent Haskell is for applications which have an inherent
structure of interacting, concurrent tasks (i.e. `threads'). Threads
in such programs may be <emphasis>required</emphasis>. For example, if a concurrent thread has been spawned to handle a mouse click, it isn't
optional—the user wants something done!
</para>
<para>
A Concurrent Haskell program implies multiple `threads' running within
a single Unix process on a single processor.
</para>
<para>
You will find at least one paper about Concurrent Haskell hanging off
of <ulink url="http://research.microsoft.com/~simonpj/">Simon Peyton
Jones's Web page</ulink>.
</para>
<para>
Parallel Haskell is about <emphasis>speed</emphasis>—spawning
threads onto multiple processors so that your program will run faster.
The `threads' are always <emphasis>advisory</emphasis>—if the
runtime system thinks it can get the job done more quickly by
sequential execution, then fine.
</para>
<para>
A Parallel Haskell program implies multiple processes running on
multiple processors, under a PVM (Parallel Virtual Machine) framework.
An MPI interface is under development but not fully functional, yet.
</para>
<para>
Parallel Haskell is still relatively new; it is more about “research
fun” than about “speed.” That will change.
</para>
<para>
Check the <ulink url="http://www.cee.hw.ac.uk/~dsg/gph/">GPH Page</ulink>
for more information on “GPH” (Haskell98 with extensions for
parallel execution), the latest version of “GUM” (the runtime
system to enable parallel executions) and papers on research issues. A
list of publications about GPH and about GUM is also available from Simon's
Web Page.
</para>
<para>
Some details about Parallel Haskell follow. For more information
about concurrent Haskell, see the module
<literal>Control.Concurrent</literal> in the library documentation.
</para>
<sect2>
<title>Features specific to Parallel Haskell
<indexterm><primary>Parallel Haskell—features</primary></indexterm></title>
<sect3>
<title>The <literal>Parallel</literal> interface (recommended)
<indexterm><primary>Parallel interface</primary></indexterm></title>
<para>
GHC provides two functions for controlling parallel execution, through
the <literal>Parallel</literal> interface:
</para>
<para>
<programlisting>
interface Parallel where
infixr 0 `par`
infixr 1 `seq`
par :: a -> b -> b
seq :: a -> b -> b
</programlisting>
</para>
<para>
The expression <literal>(x `par` y)</literal> <emphasis>sparks</emphasis> the evaluation of <literal>x</literal>
(to weak head normal form) and returns <literal>y</literal>. Sparks are queued for
execution in FIFO order, but are not executed immediately. At the
next heap allocation, the currently executing thread will yield
control to the scheduler, and the scheduler will start a new thread
(until reaching the active thread limit) for each spark which has not
already been evaluated to WHNF.
</para>
<para>
The expression <literal>(x `seq` y)</literal> evaluates <literal>x</literal> to weak head normal
form and then returns <literal>y</literal>. The <function>seq</function> primitive can be used to
force evaluation of an expression beyond WHNF, or to impose a desired
execution sequence for the evaluation of an expression.
</para>
<para>
For example, consider the following parallel version of our old
nemesis, <function>nfib</function>:
</para>
<para>
<programlisting>
import Parallel
nfib :: Int -> Int
nfib n | n <= 1 = 1
| otherwise = par n1 (seq n2 (n1 + n2 + 1))
where n1 = nfib (n-1)
n2 = nfib (n-2)
</programlisting>
</para>
<para>
For values of <varname>n</varname> greater than 1, we use <function>par</function> to spark a thread
to evaluate <literal>nfib (n-1)</literal>, and then we use <function>seq</function> to force the
parent thread to evaluate <literal>nfib (n-2)</literal> before going on to add
together these two subexpressions. In this divide-and-conquer
approach, we only spark a new thread for one branch of the computation
(leaving the parent to evaluate the other branch). Also, we must use
<function>seq</function> to ensure that the parent will evaluate <varname>n2</varname> <emphasis>before</emphasis>
<varname>n1</varname> in the expression <literal>(n1 + n2 + 1)</literal>. It is not sufficient to
reorder the expression as <literal>(n2 + n1 + 1)</literal>, because the compiler may
not generate code to evaluate the addends from left to right.
</para>
</sect3>
<sect3>
<title>Underlying functions and primitives
<indexterm><primary>parallelism primitives</primary></indexterm>
<indexterm><primary>primitives for parallelism</primary></indexterm></title>
<para>
The functions <function>par</function> and <function>seq</function> are wired into GHC, and unfold
into uses of the <function>par#</function> and <function>seq#</function> primitives, respectively. If
you'd like to see this with your very own eyes, just run GHC with the
<option>-ddump-simpl</option> option. (Anything for a good time…)
</para>
</sect3>
<sect3>
<title>Scheduling policy for concurrent threads
<indexterm><primary>Scheduling—concurrent</primary></indexterm>
<indexterm><primary>Concurrent scheduling</primary></indexterm></title>
<para>
Runnable threads are scheduled in round-robin fashion. Context
switches are signalled by the generation of new sparks or by the
expiry of a virtual timer (the timer interval is configurable with the
<option>-C[<num>]</option><indexterm><primary>-C<num> RTS option (concurrent,
parallel)</primary></indexterm> RTS option). However, a context switch doesn't
really happen until the current heap block is full. You can't get any
faster context switching than this.
</para>
<para>
When a context switch occurs, pending sparks which have not already
been reduced to weak head normal form are turned into new threads.
However, there is a limit to the number of active threads (runnable or
blocked) which are allowed at any given time. This limit can be
adjusted with the <option>-t<num></option><indexterm><primary>-t <num> RTS option (concurrent, parallel)</primary></indexterm>
RTS option (the default is 32). Once the
thread limit is reached, any remaining sparks are deferred until some
of the currently active threads are completed.
</para>
</sect3>
<sect3>
<title>Scheduling policy for parallel threads
<indexterm><primary>Scheduling—parallel</primary></indexterm>
<indexterm><primary>Parallel scheduling</primary></indexterm></title>
<para>
In GUM we use an unfair scheduler, which means that a thread continues to
perform graph reduction until it blocks on a closure under evaluation, on a
remote closure or until the thread finishes.
</para>
</sect3>
</sect2>
</sect1>
<!-- Emacs stuff:
;;; Local Variables: ***
;;; mode: xml ***
;;; sgml-parent-document: ("users_guide.xml" "book" "chapter" "sect1") ***
;;; End: ***
-->
|
