211 lines
25 KiB
TeX
211 lines
25 KiB
TeX
|
|
\section{Experiments}\label{sec:mwreexperiments}
|
|
|
|
The purpose of our experiments is twofold. We first compare in Section~\ref{sec:exp-overhead} the perfomance and overhead of our workflow engine with two related state-of-the-art workflow systems.
|
|
Second, we evaluate in Section~\ref{sec:exp-performance} the overhead of workflow execution with full-ahead scheduling to find out how well full-ahead scheduling performs on shared-memory manycore computers which exhibit completely different characteristics than DCIs.
|
|
We conducted all the experiments on a multi-core system with four Intel Xeon E7-4870 10-core CPUs at \SI{2.40}{\giga\hertz} with a total of \SI{128}{\giga\byte} of RAM. We used the GNU GCC C/C++ compiler version 4.9.1 to compile the generated workflow programs with the \texttt{-O3} optimisation flag.
|
|
|
|
\subsection{Workflow enactment performance and overhead}
|
|
\label{sec:exp-overhead}
|
|
|
|
|
|
|
|
\begin{figure}[t]
|
|
\centering
|
|
\subfloattex{Enactment time.}{0.48\columnwidth}{./mwre/figures/Povray-Runtime.tex}
|
|
\subfloattex{Memory utilisation.}{0.48\columnwidth}{./mwre/figures/Povray-Memory.tex}
|
|
\caption{Experimental results for the POV-Ray workflow.}
|
|
\label{fig:ex-povray-results}
|
|
\end{figure}
|
|
|
|
The goal of these experiments was to verify the callback-driven approach of designing the engine
|
|
and to give a general estimate of the overhead and scalability associated with maintaining a WEP on shared memory many-core systems.
|
|
Furthermore we also compared the performance and overhead of \emph{early evaluation} mode (labelled \texttt{MWRE-Early}) and \emph{late evaluation} mode (labelled \texttt{MWRE-Late}) to get an estimate on the costs of maintaining an as complete as possible WEP.
|
|
|
|
We conducted the experiments by comparing our engine with two related ones: a fully-fledged workflow environment for DCIs (ASKALON~\cite{Fahringer2007}) and a general purpose lightweight workflow scripting language (Swift~\cite{wilde2011swift}). To allow a low baseline comparison, we also implemented synthetic OpenMP versions for each workflow application, as OpenMP is the current standard for programming parallel applications on shared memory architectures. We automatically generated the MWRE workflow programs from the IWIR specifications (exported from ASKALON) and the concrete parts from the ASKALON's resource management deployment files using a Java source-to-source compiler that translates IWIR to C++. For each experiment, we recorded the enactment time of the workflow programs in both default and lazy WEP evaluation modes, and their memory utilisation. The enactment time refers to the time spend by the engine while evaluating the WEP and resolving dependencies. Regarding memory, we used the resident size reported by the operating system for MWRE and OpenMP, while for ASKALON and Swift we used the memory statistics delivered by the Java runtime API. Since there is no difference in memory consumption between \texttt{MWRE-Early} and \texttt{MWRE-Late}, we report a single joint result for both. To obtain a more accurate measure of the workflow enactment overhead and its memory consumption, we replaced the actual atomic activities with dummy implementations that only create empty files to satisfy data dependencies, and recorded the makespan of the workflow executions. We used the minimum completion time (MCT)~\cite{Maheswarana1999} scheduling algorithm in all experiments as it has low overhead, a low linear complexity, and is resilient to prediction inaccuracies.
|
|
We use a logarithmic $y$-axis in all the figures for a better visualisation.
|
|
|
|
|
|
\subsubsection{POV-Ray}
|
|
|
|
\begin{wrapfigure}{R}{0.3\textwidth}
|
|
\centering
|
|
\includegraphics[width=3cm,keepaspectratio=true]{./mwre/figures/Povray-experiments1.pdf}
|
|
\caption{Experimental POV-Ray workflow.}
|
|
\label{fig:ex-povray2}
|
|
\end{wrapfigure}
|
|
|
|
We used again the POV-Ray workflow with the simple structure presented in detail in Section~\ref{sec:workflow_environment} but without the \texttt{SceneFile} activity (see Figure~\ref{fig:ex-povray2}).
|
|
|
|
The results in Figure~\ref{fig:ex-povray-results} show that until about 2000~--~3000 activities the performance of MWRE is similar to OpenMP. Above 2000 activities the performance of \texttt{MWRE-Early} is significantly worse than OpenMP, and the performance difference increases the higher the activity count. The performance of \texttt{MWRE-Late} is slightly better, being similar to OpenMP till about 3000, and after it gets worse than OpenMP but it stays better than \texttt{MWRE-Early} showing twice the performance at about 8000 activities.
|
|
Swift is 50 times worse than MWRE for a low number of activities, but this difference decreases till it has the same performance as \texttt{MWRE-Early} and is only twice as worse than \texttt{MWRE-Late} for 8000 activities.
|
|
ASKALON's performance is 70~--120 times worse than MWRE and it can only handle about 2000 activities till it exceeds the memory available to Java.
|
|
|
|
After a rapid increase in the beginning, MWRE's memory utilization remains relatively constant between 90~--~\SI{110}{\mega\byte} and slowly increases with the number of activities. We consider this a low consumption given that real-world activity implementations typically consume gigabytes of memory. In comparison, OpenMP uses between 10~--~\SI{15}{\mega\byte}, Swift between 280~--~\SI{1000}{\mega\byte}, and ASKALON between 590~--~\SI{8500}{\mega\byte}.
|
|
|
|
|
|
|
|
\subsubsection{RainCloud}
|
|
|
|
\begin{wrapfigure}{R}{0.5\textwidth}
|
|
\centering
|
|
\includegraphics[width=6cm,keepaspectratio=true]{./mwre/figures/Raincloud-experiments1.pdf}
|
|
\caption{RainCloud workflow.}
|
|
\label{fig:ex-raincloud}
|
|
\end{wrapfigure}
|
|
|
|
RainCloud is a meteorological workflow for weather simulation in mountainous regions using a simple numerical linear model of orographic precipitations~\cite{Schuller2013}. The workflow is currently used by the Tyrolean avalanche service for their daily avalanche bulletins. Its structure, displayed in Figure\ref{fig:ex-raincloud}, is very similar to POV-Ray, but contains a few additional conditional activities. In our experiments, the conditional activities always evaluate to true so that the \texttt{PPS} and \texttt{PPF} activities are executed.
|
|
|
|
|
|
\begin{figure}[t]
|
|
\centering
|
|
\subfloattex{Enactment time.}{0.48\columnwidth}{./mwre/figures/Raincloud-Runtime.tex}
|
|
\subfloattex{Memory utilisation.}{0.48\columnwidth}{./mwre/figures/Raincloud-Memory.tex}
|
|
\caption{Experimental results for the RainCloud workflow.}
|
|
\label{fig:ex-raincloud-results}
|
|
\end{figure}
|
|
|
|
The results in Figure~\ref{fig:ex-raincloud-results} show that until about 3000 activities the performance of MWRE is similar to OpenMP. Above 3000 activities the performance of \texttt{MWRE-Early} and \texttt{MWRE-Late} is significantly worse than OpenMP, and the performance difference increases the higher the activity count. The performance of \texttt{MWRE-Late} is again significantly better than \texttt{MWRE-Early} after 3000 activities.
|
|
Swift is 40 times worse than MWRE for a low number of activities, but this difference decreases till it shows even better performance as \texttt{MWRE-Early} and is only slightly worse than \texttt{MWRE-Late} at around 9000 activities.
|
|
ASKALON's performance starts out 350 times worse than MWRE but at around 6000 activities, where it runs out of memory again, it is only 10 times worse than \texttt{MWRE-Early}.
|
|
|
|
After a rapid increase, the memory utilization of MWRE is relatively constant between 60~--~\SI{95}{\mega\byte} and slowly increases with the number of activities. In comparison, OpenMP uses between 16~--~\SI{21}{\mega\byte}, Swift between 283~--~\SI{590}{\mega\byte}, and ASKALON between 590~--~\SI{6200}{\mega\byte}.
|
|
|
|
\begin{wrapfigure}{R}{0.5\textwidth}
|
|
\centering
|
|
\includegraphics[width=6cm,keepaspectratio=true]{./mwre/figures/Montage-experiments1.pdf}
|
|
\caption{Montage workflow.}
|
|
\label{fig:ex-montage}
|
|
\end{wrapfigure}
|
|
|
|
|
|
\subsubsection{Montage}
|
|
|
|
Montage~\cite{Jacob2009} is a well-known workflow in the scientific computing community created by NASA/IPAC, which stitches together multiple images to create mosaics of the sky. Montage has a rather complex structure briefly sketched in Figure~\ref{fig:ex-montage}, making its enactment the most computationally expensive from all our workflows.
|
|
|
|
|
|
The results in Figure~\ref{fig:ex-montage-results} show that until about 600 activities the performance of MWRE is similar to OpenMP. Above 600 activities the performance of \texttt{MWRE-Early} is rapidly degrading, even getting much worse than Swift at around 2000 activities. In contrast, \texttt{MWRE-Late} always performs similar to OpenMP.
|
|
Swift starts 7 times worse than MWRE for a low number of activities, but this difference decreases till it is even twice as fast as \texttt{MWRE-Early} at around 3000 activities.
|
|
In this experiment we cannot directly compare ASKALON to the rest because ASKALON begins to exceed available memory at around 160 activities due to the internal implementation of the collection data type, extensively used for activity ports in Montage.
|
|
|
|
|
|
\begin{figure}[t]
|
|
\centering
|
|
\subfloattex{Enactment time.}{0.48\columnwidth}{./mwre/figures/Montage-Runtime.tex}
|
|
\subfloattex{Memory utilisation.}{0.48\columnwidth}{./mwre/figures/Montage-Memory.tex}
|
|
\caption{Experimental results for the Montage workflow.}
|
|
\label{fig:ex-montage-results}
|
|
\end{figure}
|
|
|
|
The memory utilisation of MWRE is relatively constant between 65~--~\SI{207}{\mega\byte} and slowly increases with the number of activities. In comparison, OpenMP uses between 21~--~\SI{30}{\mega\byte}, Swift between 312~--~\SI{6500}{\mega\byte}, and ASKALON between 614~--~\SI{9000}{\mega\byte}.
|
|
|
|
|
|
\subsubsection{Sparselu}
|
|
|
|
\begin{wrapfigure}{R}{0.5\textwidth}
|
|
\centering
|
|
\includegraphics[width=6cm,keepaspectratio=true]{./mwre/figures/Sparselu-experiments1.pdf}
|
|
\caption{Sparselu workflow.}
|
|
\label{fig:ex-sparselu}
|
|
\end{wrapfigure}
|
|
|
|
The Sparselu workflow (see Figure~\ref{fig:ex-sparselu}) adapted from the \texttt{sparselu} program from the BOTS benchmark suite~\cite{duran2009barcelona} does LU factorisation of sparse matrices. The workflow comes in two flavours: with a \texttt{for} and with a \texttt{while} sequential outermost loop. In terms of WEP generation in MWRE, there is a big difference between a \texttt{while} and a \texttt{for} loop. While we can unroll a \texttt{for} loop once we know the loop iteration counter and generate the complete WEP, this is not possible for a \texttt{while} loop that requires re-evaluation of the loop condition after each iteration with no indication on the total number of iterations. The workflow contains three consecutive \texttt{parallel for} loops with the same number of iterations within the sequential outermost loop. The experiments labelled \texttt{*-Length} in Figures~\ref{fig:ex-Sparselu-while-results} and~\ref{fig:ex-Sparselu-for-results} only modify the iteration number of the sequential outermost loop (i.e. the length of the workflow), while the experiments labelled \texttt{*-Width} only modify the iteration number of the inner \texttt{parallel for} loops (i.e. the width of the workflow). In the first case, we increase of total number of activities while keeping the number of activities scheduled at the same time constant, while in the second case we also modify the number of activities simultaneously scheduled.
|
|
|
|
\begin{figure}[t]
|
|
\centering
|
|
\subfloattex{Enactment time.}{0.48\columnwidth}{./mwre/figures/Sparselu-For-1-Runtime.tex}
|
|
\subfloattex{Memory utilisation.}{0.48\columnwidth}{./mwre/figures/Sparselu-For-1-Memory.tex}\qquad
|
|
\subfloattex{Enactment time.}{0.48\columnwidth}{./mwre/figures/Sparselu-For-2-Runtime.tex}
|
|
\subfloattex{Memory utilisation.}{0.48\columnwidth}{./mwre/figures/Sparselu-For-2-Memory.tex}
|
|
\caption{Experimental results for the \texttt{For} variant of the Sparselu workflow.}
|
|
\label{fig:ex-Sparselu-for-results}
|
|
\end{figure}
|
|
|
|
\begin{figure}[t]
|
|
\centering
|
|
\subfloattex{Enactment time.}{0.48\columnwidth}{./mwre/figures/Sparselu-While-1-Runtime.tex}
|
|
\subfloattex{Memory utilisation.}{0.48\columnwidth}{./mwre/figures/Sparselu-While-1-Memory.tex}\qquad
|
|
\subfloattex{Enactment time.}{0.48\columnwidth}{./mwre/figures/Sparselu-While-2-Runtime.tex}
|
|
\subfloattex{Memory utilisation.}{0.48\columnwidth}{./mwre/figures/Sparselu-While-2-Memory.tex}
|
|
\caption{Experimental results for the \texttt{While} variant of the Sparselu workflow.}
|
|
\label{fig:ex-Sparselu-while-results}
|
|
\end{figure}
|
|
|
|
The results in Figures~\ref{fig:ex-Sparselu-while-results} and~\ref{fig:ex-Sparselu-for-results} show that the performance of MWRE is similar to OpenMP most of the time. Also there is no significant difference in performance between the \texttt{For} and the \texttt{While} variants. However, there is a significant performance difference between the \texttt{*-Length} and the \texttt{*-Width} variants. The performance of the \texttt{*-Length} variants always stays similar to OpenMP, whereas the performance of the \texttt{*-Width} variants gets worse than OpenMP at about 30000 activities. The performance of Swift is about 4~--~7 times worse than MWRE in most cases. However, in the \texttt{*-Width} variants it is only two times worse than \texttt{MWRE-Early} at around 60000 activities. ASKALON on the other hand, is about 500~--~800 times worse than MWRE, and at around 6000 activities it again runs out of memory.
|
|
|
|
The memory utilisation of MWRE is significantly higher than in the previous experiments (between 15~--~\SI{820}{\mega\byte}), but comparable if we take into account the higher number of activities involved. In comparison, OpenMP uses between 15~--~\SI{32}{\mega\byte}s, Swift between 550~--~\SI{4100}{\mega\byte}, and ASKALON between 770~--~\SI{7200}{\mega\byte}.
|
|
|
|
|
|
\subsubsection{Discussion}
|
|
The experimental results show that MWRE has a better performance and lower memory usage than other traditional workflow systems on shared-memory manycore systems most of the time. It even shows similar performance than OpenMP in most cases. However, its scalability is limited and nearly all experiments show that at a certain workflow size the performance of MWRE begins to degrade. This is because MWRE maintains a complete WEP of the workflow in order to facilitate full-ahead scheduling. Maintaining a WEP is a complex stateful operation and at a certain size the costs of maintaining a WEP becomes too high causing poor performance. At which workflow size the costs of maintaining a WEP seems to be individual for each workflow. In our experiments a simple workflow like POV-Ray only shows similar performance to OpenMP up to 2000~--~3000 activities, whereas a more complex workflow like Sparselu can scale up to more than 60000 activities.
|
|
|
|
One of the factors that influences the scalability is the number of simultaneously scheduled activities. POV-Ray is basically a single parallel loops, which means that nearly all activities are scheduled at the same time. In contrast, Sparselu contains several parallel loops within a sequential loop which means that only a fraction of the total workflow activities are simultaneously scheduled. This is further confirmed by comparing the \texttt{*-Length} and \texttt{*-Width} variants of the Sparselu workflow. The \texttt{*-Length} variants do not change the number of simultaneously scheduled activities, and they show performance similar to OpenMP in all cases. In comparison, the \texttt{*-Width} variants do increase the number of simultaneously scheduled activities, and at around 30000 activities their performance begins to worsen.
|
|
|
|
Another factor limiting scalability seems to be the number of re-evaluations of the WEP caused by our \emph{early evaluation} policy. The most prominent example is the huge gap in the performance of \texttt{MWRE-Early} and \texttt{MWRE-Late} in the Montage workflow. Montage excessively uses \texttt{parallel ForEach} loops together with \texttt{Union}-Ports, which means that every finished loop iteration causes a notification of the successor activities that new data is available when \texttt{MWRE-Early} is used. In contrast, \texttt{MWRE-Late} only informs the successors when the complete loop has finished. Also in most other workflows \texttt{MWRE-Late} scales better than \texttt{MWRE-Early}, although the performance difference is not that dramatic. This also indicates that there is some optimization potential by finding some middle ground between \texttt{MWRE-Early} and \texttt{MWRE-Late} and thus reducing the number of re-evaluations.
|
|
|
|
The results also indicate that there is no significant performance difference between generating the complete WEP from the beginning (i.e. \texttt{For} variants of Sparselu) and successively completing the WEP as the workflow execution progresses (i.e. \texttt{While} variants of Sparselu).
|
|
|
|
|
|
\subsection{Workflow execution using full-ahead scheduling}
|
|
\label{sec:exp-performance}
|
|
|
|
We believe that full-ahead scheduling is one of the keys to success for workflows on shared-memory manycore computers. We know from DCIs that full-ahead scheduling algorithm produce a better schedule than just-in-time scheduling algorithms in most cases. But workflows on DCIs exhibit different characteristics than parallel programs on shared-memory manycore computers. While Workflows on DCIs usually consist of relatively few, long running atomic activities, parallel programs on manycores consist of a rather large number of short running tasks. Also, on DCIs the workflow engine and consequently the scheduler are implemented as extern services having their own dedicated computing resources, while on manycores the workflow engine and the scheduler have to compete with the atomic activity execution sub-system for computing resources. Because of this the scheduler has to re-evaluate the schedule more often on manycore computers leading to more overhead, while at the same time workflow execution on manycores is much more susceptible to scheduling overhead because of shared computing resources and much shorter execution times of atomic activities.
|
|
|
|
To find out whether full-ahead scheduling can still deliver its promises despite the above mentioned problems, we executed a large number of workflows exhibiting characteristics of parallel programs for manycores using a well-known full-ahead scheduling algorithm. In order to have a baseline we can compare the results to, we also executed the same workflows using a just-in-time scheduling algorithm. As full-ahead scheduling algorithm we use HEFT~\cite{Maheswarana1999} and as just-in-time algorithm we use Minimum Completion Time (MCT). HEFT is one of the most widely known full-ahead scheduling algorithms consisting of two phases. In the first phase, it recursively assigns a rank to each activity according to its highest distance to the last activity of the workflow (i.e. B-rank):
|
|
\[\mathit{rank}\left(a_i\right)=\overline{w_i}+\max_{n_j\in \mathit{succ}\left(a_i\right)}\left(\overline{c_{i,j}}+\mathit{rank}\left(a_j\right)\right),\]
|
|
where $a_i \in A$ refers to the $i$-th activity, $\overline{w_i}$ is the average execution time of activity $a_i$ across all available resources, $\mathit{succ}\left(a_i\right)$ is the set of activities that immediately depend on $a_i$, and $\overline{c_{i,j}}$ is the average communication costs of the data transferred between activities $a_i$ and $a_j \in \mathit{succ}\left(a_i\right)$ across all pairs of available resources. In the second phase, it traverses the ranked list of activities and schedules each of them using the MCT algorithm.
|
|
|
|
\begin{figure}[t]
|
|
\centering
|
|
\resizebox{\textwidth}{!}{ \input{./mwre/figures/Scheduler01-Speedup.tex}}
|
|
\caption{Speedup of HEFT versus MCT.}
|
|
\label{fig:ex-scheduling-speedup-results}
|
|
\end{figure}
|
|
|
|
To evaluate the workflow execution performance for a large number and variety of workflows, we used an algorithm for automatically generating random workflows~\cite{topcuoglu2002performance} by varying the following parameters as presented in Table~\ref{tab:wf-params}:
|
|
\begin{itemize}
|
|
\item \emph{Average number of activities} $v$ in the workflow;
|
|
\item \emph{Workflow shape} $\alpha$ by randomly generating the workflow height from a uniform distribution with a mean value equal to $\frac{\sqrt{v}}{\alpha}$, and the width of each level randomly selected from a uniform distribution with mean value $\sqrt{v}\cdot\alpha$;
|
|
\item \emph{Output degree of an activity} $o_i$ representing the maximum number of successors a workflow activity is allowed to have;
|
|
\item \emph{Computational heterogeneity} $\beta$ by randomly generating the execution time for each activity $a_i$ on each resource from the interval $\left(\overline{w_i}\cdot\left(1-\frac{\beta}{2}\right), \overline{w_i}\cdot\left(1+\frac{\beta}{2}\right)\right)$, where $\overline{w_i}$ is the average execution time of $a_i$.
|
|
\end{itemize}
|
|
|
|
\begin{wraptable}{r}{0pt}
|
|
\small
|
|
\begin{tabular}{|c|c|}
|
|
\hline
|
|
\emph{Parameter} & \emph{Value set}\\
|
|
\hline
|
|
$v$ & \{ 300, 600, 900, 1200, 2400 \}\\
|
|
$\alpha$ & \{ 1, 2, 4 \}\\
|
|
$o_i$ & \{ 2, 4, 8, 10 \}\\
|
|
$\beta$ & \{ 1, 1.9 \}\\
|
|
\hline
|
|
\end{tabular}
|
|
\caption{Random workflow generation parameters.}
|
|
\label{tab:wf-params}
|
|
\end{wraptable}
|
|
|
|
We set the computation to communication ratio parameter to zero, since on shared memory systems the communication is usually much faster than the computation. We set the average activity execution time $\overline{w}$ to five seconds to get a more realistic result for shared memory manycore systems that allow a much finer-grained parallelism compared to DCIs that feature average execution times of several minutes or hours.
|
|
|
|
We generated three different workflows for each parameter combination, recorded the average workflow execution time for each parameter combination, and computed the speedup of HEFT compared to MCT. Furthermore, we recorded the workflow enactment time (spent in the workflow engine and the scheduler) together with the queuing and actual execution time for each activity.
|
|
|
|
\begin{figure}[t!]
|
|
\centering
|
|
\subfloattex{HEFT.}{\columnwidth}{./mwre/figures/Scheduler01-Times-HEFT.tex}\qquad
|
|
\subfloattex{MCT.}{\columnwidth}{./mwre/figures/Scheduler01-Times-JIT.tex}
|
|
\caption{Cumulative time analysis of HEFT and MCT.}
|
|
\label{fig:ex-scheduling-results}
|
|
\end{figure}
|
|
|
|
Figure~\ref{fig:ex-scheduling-speedup-results} shows the speedup results of our experiments. The $x$-axis represents the parameter groups starting with 1, defined as the cross-product of the parameter values from Table~\ref{tab:wf-params}. For example, the parameter group 20 represents the parameter values $v=300$, $\alpha=4$, $o_i=4$ and $\beta=1.9$. It can be seen that HEFT generally exhibits a better performance than MCT for a large number of workflows, with performance gains of up to 40\%. The number of activities $v$ does not have a significant impact on performance in our experiment. In contrast, the shape parameter $\alpha$ significantly influence performance. For $\alpha=1$ (parameter groups 1~--~8, 25~--~32, 49~--~56, 73~--~80 and 97~--~104), we hardly obtain any speedup and get even slowdowns. Only for $\alpha>1$ we obtain significant speedups. The parameter $\alpha$ controls the height and width of a workflow, and the higher its value the more parallelism a workflow contains. This means that a workflow needs a minimal amount of parallelism for full-ahead scheduling to produce good results. The influence of the parameters $o_i$ and $\beta$ on the speedup cannot be clearly determined. There are some indications that higher values of $o_i$ and $\beta$ tend to produce a better speedups, but the differences are smaller than the error distribution. Therefore, they are not significant enough for a conclusion.
|
|
|
|
Figure~\ref{fig:ex-scheduling-results} with a logarithmic $y$-axis shows the cumulative sum of enactment times, activity queuing times and activity execution times. The $x$-axis again represents the parameter groups. In this figure, the number of nodes $v$ significantly impacts the enactment time. The number of nodes grows with the growing parameter group number, as also the enactment time for both HEFT and MCT. The activity queuing time is influenced by both number of nodes $v$ and workflow shape $\alpha$. The higher the number of nodes $v$ the higher the average queue time. But there are also sudden jumps in the queue time which correspond with the workflow shape $\alpha$ being set to 2 (the smaller jumps like e.g. at parameter group 57~--~64) and being set to 4 (the higher jumps like e.g. at parameter group 65~--~72). When we compare the results of HEFT with the results of MCT then we see that HEFT has higher enactment time, which is proportional to the number of nodes $v$, than MCT. Nevertheless, the enactment time is in all instances still much smaller than the sum of queue times and execution times. But HEFT has a lower activity queue time than MCT. When we look at the total times, then the lower queue times more than compensate for the higher enactment times so that in the end HEFT has a better performance than MCT in most cases.
|
|
|
|
|
|
|
|
|
|
The results clearly show that workflow execution on shared-memory manycores using a full-ahead scheduling algorithm can still gain significant performance compared to just-in-time scheduling, despite suffering from a higher overhead compared to workflow execution on DCIs and manycore computers being more susceptible to overhead. Even with a low average activity execution time of only five seconds, the overhead caused by the WEP generation and full-ahead scheduling algorithm stays in an acceptable range.
|
|
|
|
|