- 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>
+ n2 = nfib (n-2)</programlisting>
+
+ <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>
+
+ <para>When using <literal>par</literal>, the general rule of thumb is that
+ the sparked computation should be required at a later time, but not too
+ soon. Also, the sparked computation should not be too small, otherwise
+ the cost of forking it in parallel will be too large relative to the
+ amount of parallelism gained. Getting these factors right is tricky in
+ practice.</para>
+
+ <para>More sophisticated combinators for expressing parallelism are
+ available from the <ulink
+ url="../libraries/base/Control-Parallel-Strategies.html"><literal>Control.Parallel.Strategies</literal></ulink> module.
+ This module builds functionality around <literal>par</literal>,
+ expressing more elaborate patterns of parallel computation, such as
+ parallel <literal>map</literal>.</para>
+ </sect2>