Uni/phd-thesis
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

.

Browse Source
This commit is contained in:
matzman
2017-10-13 17:02:31 +02:00
parent 7d03ad7051
commit 8a86545c86
55 changed files with 10483 additions and 1759 deletions
Download Patch File Download Diff File Expand all files Collapse all files
workflowtransformations/workflowtransformations-transformations.tex
+18 -18
View File
@@ -36,12 +36,12 @@ We plan to investigate further workflow-specific transformations in future work.
\begin{figure*}[t]
\centering
\subfloat[Loop-invariant code hosting.]{\includegraphics[width=.3\textwidth]{./figures/transformation-loopInvariantHoisting.pdf}\label{fig:transformation-loopInvariantHoisting}}
\subfloat[Common subexpression elimination.]{\includegraphics[width=.3\textwidth]{./figures/transformation-CommonSubexpressionElimination.pdf}\label{fig:transformation-CommonSubexpressionElimination}}
\subfloat[If optimization.]{\includegraphics[width=.25\textwidth]{./figures/transformation-IfOptimization.pdf}\label{fig:transformation-IfOptimization}}\\
\subfloat[Reduction recognition.]{\includegraphics[width=.3\textwidth]{./figures/transformation-ReductionRecognition.pdf}\label{fig:transformation-ReductionRecognition}}
\subfloat[Code hoisting.]{\includegraphics[width=.3\textwidth]{./figures/transformation-CodeHoisting.pdf}\label{fig:transformation-CodeHoisting}}
\subfloat[Software pipelining.]{\includegraphics[width=.3\textwidth]{./figures/transformation-SoftwarePipelining.pdf}\label{fig:transformation-SoftwarePipelining}}
\subfloat[Loop-invariant code hosting.]{\includegraphics[width=.3\textwidth]{./workflowtransformations/figures/transformation-loopInvariantHoisting.pdf}\label{fig:transformation-loopInvariantHoisting}}
\subfloat[Common subexpression elimination.]{\includegraphics[width=.3\textwidth]{./workflowtransformations/figures/transformation-CommonSubexpressionElimination.pdf}\label{fig:transformation-CommonSubexpressionElimination}}
\subfloat[If optimization.]{\includegraphics[width=.25\textwidth]{./workflowtransformations/figures/transformation-IfOptimization.pdf}\label{fig:transformation-IfOptimization}}\\
\subfloat[Reduction recognition.]{\includegraphics[width=.3\textwidth]{./workflowtransformations/figures/transformation-ReductionRecognition.pdf}\label{fig:transformation-ReductionRecognition}}
\subfloat[Code hoisting.]{\includegraphics[width=.3\textwidth]{./workflowtransformations/figures/transformation-CodeHoisting.pdf}\label{fig:transformation-CodeHoisting}}
\subfloat[Software pipelining.]{\includegraphics[width=.3\textwidth]{./workflowtransformations/figures/transformation-SoftwarePipelining.pdf}\label{fig:transformation-SoftwarePipelining}}
\caption{Example workflow transformations.}
\label{fig:example-transformations}
\end{figure*}
@@ -51,20 +51,20 @@ We plan to investigate further workflow-specific transformations in future work.
This category represents transformations that eliminate redundant atomic activity invocations (the most expensive parts in the workflow enactment),
with a possible huge impact on performance. This category is similar to traditional transformations trying to reduce the number of executed instructions (replaced by activities here) such as loop-invariant code hoisting, common subexpression/activity elimination and constant propagation.
\paragraph{Loop-invariant code hoisting} moves the loop-invariant code to be executed only once before the loop instead of every loop iteration. With workflow applications, this transformation moves atomic activities with loop-invariant input data outside of the loop, reducing the number of activity invocations. Figure~\ref{fig:transformation-loopInvariantHoisting} shows an example where the activity \texttt{A2} only has a loop-invariant data dependency on activity \texttt{A1} and can be moved out of the loop. Section~\ref{sec:experiments} features an example of loop-invariant code hoisting.
\paragraph{Loop-invariant code hoisting} moves the loop-invariant code to be executed only once before the loop instead of every loop iteration. With workflow applications, this transformation moves atomic activities with loop-invariant input data outside of the loop, reducing the number of activity invocations. Figure~\ref{fig:transformation-loopInvariantHoisting} shows an example where the activity \texttt{A2} only has a loop-invariant data dependency on activity \texttt{A1} and can be moved out of the loop. Section~\ref{sec:transformationexperiments} features an example of loop-invariant code hoisting.
%\begin{figure}[t]
% \centering
% \includegraphics[width=.5\columnwidth]{./figures/transformation-loopInvariantHoisting.pdf}
% \includegraphics[width=.5\columnwidth]{./workflowtransformations/figures/transformation-loopInvariantHoisting.pdf}
% \caption{Loop-Invariant Code Hosting.}
% \label{fig:transformation-loopInvariantHoisting}
%\end{figure}
\paragraph{Common subexpression/activity elimination} searches for several instances of identical expressions evaluated to the same value, and replaces them with a variable holding the computed value. We use this transformation in workflow applications to eliminate several invocations of the same activity type with the same input values. In case of an execution path between two invocations, we eliminate the redundant second invocation and connect its involved ports to the output ports of the first invocation. In the example from Figure~\ref{fig:transformation-loopInvariantHoisting}, the activities \texttt{B1} and \texttt{B2} share the same activity type and the same input values, and \texttt{B2} is reachable from \texttt{B1}. In this case, we eliminate \texttt{B2} and connect the input ports of activity \texttt{D} with the output ports of \texttt{B1}. Section~\ref{sec:experiments} features an example of common activity elimination.
\paragraph{Common subexpression/activity elimination} searches for several instances of identical expressions evaluated to the same value, and replaces them with a variable holding the computed value. We use this transformation in workflow applications to eliminate several invocations of the same activity type with the same input values. In case of an execution path between two invocations, we eliminate the redundant second invocation and connect its involved ports to the output ports of the first invocation. In the example from Figure~\ref{fig:transformation-loopInvariantHoisting}, the activities \texttt{B1} and \texttt{B2} share the same activity type and the same input values, and \texttt{B2} is reachable from \texttt{B1}. In this case, we eliminate \texttt{B2} and connect the input ports of activity \texttt{D} with the output ports of \texttt{B1}. Section~\ref{sec:transformationexperiments} features an example of common activity elimination.
%\begin{figure}[t]
% \centering
% \includegraphics[width=.75\columnwidth]{./figures/transformation-CommonSubexpressionElimination.pdf}
% \includegraphics[width=.75\columnwidth]{./workflowtransformations/figures/transformation-CommonSubexpressionElimination.pdf}
% \caption{Common subexpression elimination.}
% \label{fig:transformation-CommonSubexpressionElimination}
%\end{figure}
@@ -81,11 +81,11 @@ There exists no equivalent category in traditional compiler transformations, as
\paragraph{Loop unswitching} moves a conditional activity out of a loop and duplicates the loop in each branch of the condition. This way, the condition is only evaluated once instead of every loop iteration thus simplifying the WEP.
%Applying this transformation to a workflow produces a WEP that only contains a single set of nodes encompassing the loop, instead of a set of nodes within each loop iteration, thus reducing the number of nodes in the WEP.
Section~\ref{sec:experiments} features a loop unswitching example applied to a real-world workflow. The WEP of the original version of this workflow (see Figure~\ref{fig:raincloud-structure1}) features four, respectively three nodes per iteration, while loop unswitching (see Figure~\ref{fig:raincloud-structure2}) reduces it to two, respectively one node per iteration.
Section~\ref{sec:transformationexperiments} features a loop unswitching example applied to a real-world workflow. The WEP of the original version of this workflow (see Figure~\ref{fig:raincloud-structure1}) features four, respectively three nodes per iteration, while loop unswitching (see Figure~\ref{fig:raincloud-structure2}) reduces it to two, respectively one node per iteration.
\paragraph{Loop unrolling} replicates the loop body several times, so that a single iteration of the modified loop does the same computation as several iterations of the original loop, reducing the number of iterations needed to get the same result.
%Applying this transformation to a workflow application allows us to reduce the number of loop iteration nodes in the WEP and the number of invocations of the associated callback function, which improves scalability.
Section~\ref{sec:experiments} features an example of a loop unrolled ten times that reduces the number of loop iteration nodes nodes in the WEP and the number of loop iteration callback invocations by a factor of ten (see Figure~\ref{fig:raincloud-structure3}).
Section~\ref{sec:transformationexperiments} features an example of a loop unrolled ten times that reduces the number of loop iteration nodes nodes in the WEP and the number of loop iteration callback invocations by a factor of ten (see Figure~\ref{fig:raincloud-structure3}).
\paragraph{If optimization} combines consecutive conditional activities with equivalent conditions into a single one, and flattens the nested conditional activities when the inner condition always evaluates to true and the outer condition is true, resulting in a simpler WEP.
%When applied to a workflow application, the WEP of the modified workflow contains fewer conditional nodes and, therefore, features less overhead when traversing the WEP and evaluating the nodes.
@@ -93,7 +93,7 @@ Figure~\ref{fig:transformation-IfOptimization} shows an example of two consecuti
%\begin{figure}[ht]
% \centering
% \includegraphics[width=4cm,keepaspectratio=true]{./figures/transformation-IfOptimization.pdf}
% \includegraphics[width=4cm,keepaspectratio=true]{./workflowtransformations/figures/transformation-IfOptimization.pdf}
% \caption{If Optimization.}
% \label{fig:transformation-IfOptimization}
%\end{figure}
@@ -107,12 +107,12 @@ Examples of transformations that do not modify data access patterns and can be a
\paragraph{Reduction recognition} recognizes array operations (usually the output of a loop) reduced to a single value. Associative reduction operations can be parallelized by splitting the loop and spawning several parallel reduction operations, each reducing a part of the array, followed by a final reduction operation that reduces the partial results.
To be able to recognize activities suitable for parallel reduction, we tag them with an \texttt{associative} tag.
Figure~\ref{fig:transformation-ReductionRecognition} shows an example of a parallel loop producing an array reduced by the activity \texttt{R}. Reduction recognition splits the original loop in several loops that are executed and reduced in parallel by the activities \texttt{Rp}, followed by a final reduction \texttt{Rf}. Section~\ref{sec:experiments} features an example of reduction recognition.
Figure~\ref{fig:transformation-ReductionRecognition} shows an example of a parallel loop producing an array reduced by the activity \texttt{R}. Reduction recognition splits the original loop in several loops that are executed and reduced in parallel by the activities \texttt{Rp}, followed by a final reduction \texttt{Rf}. Section~\ref{sec:transformationexperiments} features an example of reduction recognition.
%This allows us to improve parallel performance because instead of a single activity~\texttt{R} we have several parallel activities~\texttt{Rp} executing at the same time.
%\begin{figure}[ht]
% \centering
% \includegraphics[width=4cm,keepaspectratio=true]{./figures/transformation-ReductionRecognition.pdf}
% \includegraphics[width=4cm,keepaspectratio=true]{./workflowtransformations/figures/transformation-ReductionRecognition.pdf}
% \caption{Reduction Recognition.}
% \label{fig:transformation-ReductionRecognition}
%\end{figure}
@@ -126,7 +126,7 @@ Figure~\ref{fig:transformation-CodeHoisting} shows an example workflow containin
%\begin{figure}[ht]
% \centering
% \includegraphics[width=4cm,keepaspectratio=true]{./figures/transformation-CodeHoisting.pdf}
% \includegraphics[width=4cm,keepaspectratio=true]{./workflowtransformations/figures/transformation-CodeHoisting.pdf}
% \caption{Code Hoisting.}
% \label{fig:transformation-CodeHoisting}
%\end{figure}
@@ -134,11 +134,11 @@ Figure~\ref{fig:transformation-CodeHoisting} shows an example workflow containin
\paragraph{Software pipelining} parallelizes a sequential loop containing a linear sequence of operations by overlapping the individual loop iterations. This transformation can also be applied to a workflow to improve its parallel throughput.
Figure~\ref{fig:transformation-SoftwarePipelining} shows a workflow consisting of a sequential loop with three activities \texttt{A}, \texttt{B} and \texttt{C} in a pipeline. The index \texttt{i} in the parenthesis refers to the loop iteration. The output of activity \texttt{A(i)} is input into the activity \texttt{A(i+1)} via a loop port, which hinders the use a \texttt{parallel for} loop. Software pipelining executes the activities \texttt{A(i+2)}, \texttt{B(i+1)} and \texttt{C(i)} in parallel, which improves parallelism and reduces the execution time
(see Section~\ref{sec:experiments}).% features an example of software pipelining.
(see Section~\ref{sec:transformationexperiments}).% features an example of software pipelining.
%\begin{figure}[ht]
% \centering
% \includegraphics[width=6cm,keepaspectratio=true]{./figures/transformation-SoftwarePipelining.pdf}
% \includegraphics[width=6cm,keepaspectratio=true]{./workflowtransformations/figures/transformation-SoftwarePipelining.pdf}
% \caption{Software Pipelining}
% \label{fig:transformation-SoftwarePipelining}
%\end{figure}