\begin{slide}{Funktionales und paralleles Programmieren}

(rein) funktionales Programmieren:

\begin{itemize}
\item 
  keine (Neben-)Wirkungen, keine Zuweisungen,
\item
  alle \glqq Variablen\grqq\ 
  und \glqq  Objekte\grqq\ sind konstant,
\item
  nur Auswertung von Unterprogrammen,
\end{itemize}

\emph{ist trivial parallelisierbar und thread-sicher}:

alle Argumente eines Unterprogrammes können
parallel ausgewertet werden.


\end{slide}


\begin{slide}{Parallele Auswertungsstrategien}

Steuern der Auswertung von Ausdruck \verb|x|
durch Angabe einer Strategie \verb|s|,

\verb|x `using` s|

Beispiel: \verb|x `using` rpar|
startet \emph{spark} für Auswertung von $x$,

dieser kann vom Laufzeitsystem \emph{konvertiert},
d. h. einem Thread zugeordnet werden.

\bigskip

\url{http://hackage.haskell.org/packages/archive/parallel/3.2.0.2/doc/html/Control-Parallel-Strategies.html}

\bigskip
Beispiele: Summation, Mergesort

\end{slide}

\begin{slide}{Strategien}
\begin{verbatim}
import Control.Parallel.Strategies
main = do
  let top = 100000000 ; threads = 4
  print $ psum $ do 
    t <- [ 0 .. threads - 1 ] 
    return $ sum [ t, t + threads .. top - 1 ]
psum []  = 0          
psum (x : xs) = (x `using` rpar)  + psum xs
\end{verbatim}
\end{slide}

\begin{slide}{Funktionales und paralleles Programmieren}

Pro:
\begin{itemize}\itemsep 1pt\parskip 0pt
\item leichte Parallelisierbarkeit für deklarativen Code
\item deklaratives Modell für imperativen Code
  (MVar, STM)
\end{itemize}

Con:
\begin{itemize}\itemsep 1pt\parskip 0pt
\item lazy evaluation
\item garbage collection
\end{itemize}

aber:
\begin{itemize}\itemsep 1pt\parskip 0pt
\item lazy evaluation ist selbst eine Form der
  Nebenläufigkeit (vgl. Iteratoren in OO)
\item Nebenläufige garbage-collection wollen 
  viele andere auch
\end{itemize}

\end{slide}
