\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[english]{babel}
-\usepackage{algorithm,algorithmicx,algpseudocode}
+\usepackage{algpseudocode}
\usepackage{graphicx,graphics}
\usepackage{subfig}
\usepackage{listings}
\begin{document}
\title{Dynamic Frequency Scaling for Energy Consumption
- Reduction in Distributed MPI Programs}
+ Reduction in Synchronous Distributed Applications}
\author{%
\IEEEauthorblockN{%
\begin{abstract}
Dynamic Voltage Frequency Scaling (DVFS) can be applied to modern CPUs. This
technique is usually used to reduce the energy consumed by a CPU while
- computing. Indeed, power consumption by a processor at a given time is
- exponentially related to its frequency. Thus, decreasing the frequency
+ computing. Thus, decreasing the frequency
reduces the power consumed by the CPU. However, it can also significantly
affect the performance of the executed program if it is compute bound and if a
- low CPU frequency is selected. The performance degradation ratio can even be
- higher than the saved energy ratio. Therefore, the chosen scaling factor must
+ low CPU frequency is selected. Therefore, the chosen scaling factor must
give the best possible trade-off between energy reduction and performance.
In this paper we present an algorithm that predicts the energy consumed with
consumption by the CPU and the performance of the application. The main
objective of HPC systems is to execute as fast as possible the application.
Therefore, our algorithm selects the scaling factor online with very small
-footprint. The proposed algorithm takes into account the communication times of
+overhead. The proposed algorithm takes into account the communication times of
the MPI program to choose the scaling factor. This algorithm has the ability to
predict both energy consumption and execution time over all available scaling
factors. The prediction achieved depends on some computing time information,
-gathered at the beginning of the runtime. We apply this algorithm to seven MPI
-benchmarks. These MPI programs are the NAS parallel benchmarks (NPB v3.3)
-developed by NASA~\cite{44}. Our experiments are executed using the simulator
+gathered at the beginning of the runtime. We apply this algorithm to the NAS parallel benchmarks (NPB v3.3)~\cite{44}. Our experiments are executed using the simulator
SimGrid/SMPI v3.10~\cite{Casanova:2008:SGF:1397760.1398183} over an homogeneous
distributed memory architecture. Furthermore, we compare the proposed algorithm
with Rauber and Rünger methods~\cite{3}. The comparison's results show that our
algorithm gives better energy-time trade-off.
This paper is organized as follows: Section~\ref{sec.relwork} presents some
-related works from other authors. Section~\ref{sec.exe} explains the execution
-of parallel tasks and the sources of slack times. It also presents an energy
+related works from other authors. Section~\ref{sec.exe} presents an energy
model for homogeneous platforms. Section~\ref{sec.mpip} describes how the
performance of MPI programs can be predicted. Section~\ref{sec.compet} presents
the energy-performance objective function that maximizes the reduction of energy
gears and the execution time and the energy consumed with each frequency
gear are measured. Then a heuristic or an exact method uses the retrieved
information to compute the values of the scaling factor for the processors.
-In~\cite{29}, Xie et al. use an exact exponential breadth-first search algorithm
-to compute the scaling factor values that give the optimal energy reduction
-while respecting a deadline for a sequential program. They also present a
-linear heuristic that approximates the optimal solution. In~\cite{8} , Rountree
-et al. use a linear programming algorithm, while in~\cite{38,34}, Cochran et
+In~\cite{8} , Rountree et al. use a linear programming algorithm, while in~\cite{34}, Cochran et
al. use a multi-logistic regression algorithm for the same goal. The main
drawback of these methods is that they all require executing the
whole program or, a part of it, on all frequency gears for each new instance of the same program.
using a multimeter, the slack times, \dots{} Then a method will exploit these
measurements to compute the scaling factor values for each processor. This
operation, measurements and computing new scaling factor, can be repeated as
-much as needed if the iterations are not regular. Kimura, Peraza, Yu-Liang et
-al.~\cite{11,2,31} used varied heuristics to select the appropriate scaling
+much as needed if the iterations are not regular. Peraza, Yu-Liang et
+al.~\cite{2,31} used varied heuristics to select the appropriate scaling
factor values to eliminate the slack times during runtime. However, as seen
-in~\cite{39,19}, machine learning methods can take a lot of time to converge
+in~\cite{19}, machine learning method takes a lot of time to converge
when the number of available gears is big. To reduce the impact of slack times,
in~\cite{1}, Lim et al. developed an algorithm that detects the communication
sections and changes the frequency during these sections only. This approach
might change the frequency of each processor many times per iteration if an
iteration contains more than one communication section. In~\cite{3}, Rauber and
-Rünger used an analytical model that can predict the consumed energy and the
-execution time for every frequency gear after measuring the consumed energy and
-the execution time with the highest frequency gear. These predictions may be
-used to choose the optimal gear for each processor executing the parallel
-program to reduce energy consumption. To maintain the performance of the
-parallel program , they set the processor with the biggest load to the highest
-gear and then compute the scaling factor values for the rest of the processors.
-Although this model was built for parallel architectures, it can be adapted to
-distributed architectures by taking into account the communications. The
-primary contribution of our paper is to present a new online scaling factor
-selection method which has the following characteristics:
-\begin{enumerate}
-\item It is based on Rauber and Rünger analytical model to predict the energy
- consumption of the application with different frequency gears.
-\item It selects the frequency scaling factor for simultaneously optimizing
- energy reduction and maintaining performance.
-\item It is well adapted to distributed architectures because it takes into
- account the communication time.
-\item It is well adapted to distributed applications with imbalanced tasks.
-\item It has a very small footprint when compared to other methods
+Rünger used an analytical model that can predict the consumed energy for every frequency gear after measuring the consumed energy. They
+maintain the performance as mush as possible by setting the highest frequency gear to the slowest task.
+
+The primary contribution of
+our paper is to present a new online scaling factor selection method which has the
+ following characteristics:\\
+1) It is based on Rauber and Rünger analytical model to predict the energy
+ consumption of the application with different frequency gears.
+2) It selects the frequency scaling factor for simultaneously optimizing
+ energy reduction and maintaining performance.
+3) It is well adapted to distributed architectures because it takes into
+ account the communication time.
+4) It is well adapted to distributed applications with imbalanced tasks.
+5) It has a very small overhead when compared to other methods
(e.g.,~\cite{19}) and does not require profiling or training as
- in~\cite{38,34}.
-\end{enumerate}
+ in~\cite{34}.
-\section{Execution and energy of parallel tasks on homogeneous platform}
-\label{sec.exe}
-
% \JC{The whole subsection ``Parallel Tasks Execution on Homogeneous Platform'',
% can be deleted if we need space, we can just say we are interested in this
% paper in homogeneous clusters}
-\subsection{Parallel tasks execution on homogeneous platform}
-
-A homogeneous cluster consists in identical nodes in terms of hardware and
-software. Each node has its own memory and at least one processor which can be
-a multi-core. The nodes are connected via a high bandwidth network. Tasks
-executed on this model can be either synchronous or asynchronous. In this paper
-we consider execution of the synchronous tasks on distributed homogeneous
-platform. These tasks can exchange the data via synchronous message passing.
-\begin{figure*}[t]
- \centering
- \subfloat[Sync. imbalanced communications]{%
- \includegraphics[scale=0.67]{fig/commtasks}\label{fig:h1}}
- \subfloat[Sync. imbalanced computations]{%
- \includegraphics[scale=0.67]{fig/compt}\label{fig:h2}}
- \caption{Parallel tasks on homogeneous platform}
- \label{fig:homo}
-\end{figure*}
-Therefore, the execution time of a task consists in the computation time and the
-communication time. Moreover, the synchronous communications between tasks can
-lead to slack times while tasks wait at the synchronization barrier for other
-tasks to finish their tasks (see figure~(\ref{fig:h1})). The imbalanced
-communications happen when nodes have to send/receive different amounts of data
-or they communicate with different numbers of nodes. Other sources of slack
-times are imbalanced computations. This happens when processing different
-amounts of data on each processor (see figure~(\ref{fig:h2})). In this case the
-fastest tasks have to wait at the synchronization barrier for the slowest ones
-to begin the next task. In both cases the overall execution time of the program
-is the execution time of the slowest task as in EQ~(\ref{eq:T1}).
-\begin{equation}
- \label{eq:T1}
- \textit{Program Time} = \max_{i=1,2,\dots,N} T_i
-\end{equation}
-where $T_i$ is the execution time of task $i$ and all the tasks are executed
-concurrently on different processors.
-
-\subsection{Energy model for homogeneous platform}
+\section{Energy model for homogeneous platform}
+\label{sec.exe}
Many researchers~\cite{9,3,15,26} divide the power consumed by a processor into
two power metrics: the static and the dynamic power. While the first one is
consumed as long as the computing unit is on, the latter is only consumed during
\end{equation}
The value of the scaling factor $S$ is greater than 1 when changing the
frequency of the CPU to any new frequency value~(\emph{P-state}) in the
-governor. The CPU governor is an interface driver supplied by the operating
-system's kernel to lower a core's frequency. This factor reduces quadratically
+governor. This factor reduces quadratically
the dynamic power which may cause degradation in performance and thus, the
increase of the static energy because the execution time is increased~\cite{36}.
If the tasks are sorted according to their execution times before scaling in a
P_\textit{static} \cdot T_1 \cdot S_1 \cdot N
\hfill
\end{equation}
-where $N$ is the number of parallel nodes, $T_i$ and $S_i$ for $i=1,\dots,N$ are
+where $N$ is the number of parallel nodes, $T_i$ for $i=1,\dots,N$ are
the execution times and scaling factors of the sorted tasks. Therefore, $T1$ is
the time of the slowest task, and $S_1$ its scaling factor which should be the
highest because they are proportional to the time values $T_i$. The scaling
\label{sec.mpip}
The performance (execution time) of parallel synchronous MPI applications depends
-on the time of the slowest task as in figure~(\ref{fig:homo}). If there is no
+on the time of the slowest task. If there is no
communication and the application is not data bounded, the execution time of a
parallel program is linearly proportional to the operational frequency and any
DVFS operation for energy reduction increases the execution time of the parallel
The second problem is that the optimization operation for both energy and
performance is not in the same direction. In other words, the normalized energy
and the performance curves are not at the same direction see
-figure~(\ref{fig:r2}). While the main goal is to optimize the energy and
+Figure~(\ref{fig:r2}). While the main goal is to optimize the energy and
performance in the same time. According to the equations~(\ref{eq:enorm})
and~(\ref{eq:pnorm}), the scaling factor $S$ reduce both the energy and the
performance simultaneously. But the main objective is to produce maximum energy
T_\textit{Max Comm Old}}{T_\textit{Max Comp Old} \cdot S +
T_\textit{Max Comm Old}}
\end{equation}
-\begin{figure*}
+\begin{figure}
\centering
- \subfloat[Converted relation.]{%
- \includegraphics[width=.4\textwidth]{fig/file}\label{fig:r1}}%
- \qquad%
\subfloat[Real relation.]{%
- \includegraphics[width=.4\textwidth]{fig/file3}\label{fig:r2}}
- \label{fig:rel}
+ \includegraphics[width=.5\linewidth]{fig/file3}\label{fig:r2}}%
+ \subfloat[Converted relation.]{%
+ \includegraphics[width=.5\linewidth]{fig/file}\label{fig:r1}}
\caption{The energy and performance relation}
-\end{figure*}
-Then, we can modelize our objective function as finding the maximum distance
+\end{figure}
+Then, we can model our objective function as finding the maximum distance
between the energy curve EQ~(\ref{eq:enorm}) and the inverse of performance
curve EQ~(\ref{eq:pnorm_en}) over all available scaling factors. This
represents the minimum energy consumption with minimum execution time (better
-performance) at the same time, see figure~(\ref{fig:r1}). Then our objective
+performance) at the same time, see Figure~(\ref{fig:r1}). Then our objective
function has the following form:
\begin{equation}
\label{eq:max}
- Max Dist = \max_{j=1,2,\dots,F}
+ \textit{Max Dist} = \max_{j=1,2,\dots,F}
(\overbrace{P^{-1}_\textit{Norm}(S_j)}^{\text{Maximize}} -
\overbrace{E_\textit{Norm}(S_j)}^{\text{Minimize}} )
\end{equation}
\section{Optimal scaling factor for performance and energy}
\label{sec.optim}
-Algorithm~\ref{EPSA} computes the optimal scaling factor according to the
-objective function described above.
-\begin{algorithm}[tp]
- \caption{Scaling factor selection algorithm}
- \label{EPSA}
+Algorithm on Figure~\ref{EPSA} computes the optimal scaling factor according to
+the objective function described above.
+\begin{figure}[tp]
\begin{algorithmic}[1]
+ % \footnotesize
\State Initialize the variable $Dist=0$
\State Set dynamic and static power values.
\State Set $P_{states}$ to the number of available frequencies.
\EndFor
\State Return $S_{opt}$
\end{algorithmic}
-\end{algorithm}
+ \caption{Scaling factor selection algorithm}
+ \label{EPSA}
+\end{figure}
The proposed algorithm works online during the execution time of the MPI
program. It selects the optimal scaling factor after gathering the computation
and communication times from the program after one iteration. Then the program
changes the new frequencies of the CPUs according to the computed scaling
-factors. This algorithm has a small execution time: for a homogeneous cluster
-composed of nodes having the characteristics presented in
-table~\ref{table:platform}, it takes \np[ms]{0.00152} on average for 4 nodes and
-\np[ms]{0.00665} on average for 32 nodes. The algorithm complexity is $O(F\cdot
-N)$, where $F$ is the number of available frequencies and $N$ is the number of
-computing nodes. The algorithm is called just once during the execution of the
-program. The DVFS algorithm~(\ref{dvfs}) shows where and when the algorithm is
-called in the MPI program.
-\begin{table}[htb]
- \caption{Platform file parameters}
- % title of Table
- \centering
- \begin{tabular}{|*{7}{l|}}
- \hline
- Max & Min & Backbone & Backbone & Link & Link & Sharing \\
- Freq. & Freq. & Bandwidth & Latency & Bandwidth & Latency & Policy \\
- \hline
- \np{2.5} & \np{800} & \np[GBps]{2.25} & \np[$\mu$s]{0.5} & \np[GBps]{1} & \np[$\mu$s]{50} & Full \\
- GHz & MHz & & & & & Duplex \\
- \hline
- \end{tabular}
- \label{table:platform}
-\end{table}
-
-\begin{algorithm}[tp]
- \caption{DVFS}
- \label{dvfs}
+factors. In our experiments over a homogeneous cluster described in
+section~\ref{sec.expe}, this algorithm has a small execution time. It takes
+\np[$\mu$s]{1.52} on average for 4 nodes and \np[$\mu$s]{6.65} on average for 32
+nodes. The algorithm complexity is $O(F\cdot N)$, where $F$ is the number of
+available frequencies and $N$ is the number of computing nodes. The algorithm
+is called just once during the execution of the program. The DVFS
+algorithm~(Fig.~\ref{dvfs}) shows where and when the algorithm is called in the
+MPI program.
+%\begin{table}[htb]
+% \caption{Platform file parameters}
+% % title of Table
+% \centering
+% \begin{tabular}{|*{7}{l|}}
+% \hline
+% Max & Min & Backbone & Backbone & Link & Link & Sharing \\
+% Freq. & Freq. & Bandwidth & Latency & Bandwidth & Latency & Policy \\
+% \hline
+% \np{2.5} & \np{800} & \np[GBps]{2.25} & \np[$\mu$s]{0.5} & \np[GBps]{1} & \np[$\mu$s]{50} & Full \\
+% GHz & MHz & & & & & Duplex \\
+% \hline
+% \end{tabular}
+% \label{table:platform}
+%\end{table}
+
+\begin{figure}[tp]
\begin{algorithmic}[1]
+ % \footnotesize
\For {$k:=1$ to \textit{some iterations}}
\State Computations section.
\State Communications section.
\If {$(k=1)$}
\State Gather all times of computation and\newline\hspace*{3em}%
communication from each node.
- \State Call algorithm~\ref{EPSA} with these times.
+ \State Call algorithm from Figure~\ref{EPSA} with these times.
\State Compute the new frequency from the\newline\hspace*{3em}%
- returned optimal scaling factor.
+ returned optimal scaling factor.
\State Set the new frequency to the CPU.
\EndIf
\EndFor
\end{algorithmic}
-\end{algorithm}
+ \caption{DVFS algorithm}
+ \label{dvfs}
+\end{figure}
After obtaining the optimal scaling factor, the program calculates the new
frequency $F_i$ for each task proportionally to its time value $T_i$. By
substitution of EQ~(\ref{eq:s}) in EQ~(\ref{eq:si}), we can calculate the new
\section{Experimental results}
\label{sec.expe}
Our experiments are executed on the simulator SimGrid/SMPI v3.10. We configure
-the simulator to use a homogeneous cluster with one core per node. The detailed
-characteristics of our platform file are shown in
-table~(\ref{table:platform}). Each node in the cluster has 18 frequency values
+the simulator to use a homogeneous cluster with one core per node.
+%The detailed characteristics of our platform file are shown in Table~(\ref{table:platform}).
+Each node in the cluster has 18 frequency values
from \np[GHz]{2.5} to \np[MHz]{800} with \np[MHz]{100} difference between each
-two successive frequencies. The simulated network link is \np[GB]{1} Ethernet
-(TCP/IP). The backbone of the cluster simulates a high performance switch.
+two successive frequencies. The nodes are connected via an ethernet network with 1Gbit/s bandwidth.
\subsection{Performance prediction verification}
scaling factors on 8 or 9 nodes (depending on the benchmark) to produce real
execution time values. These scaling factors are computed by dividing the
maximum frequency by the new one see EQ~(\ref{eq:s}).
-\begin{figure*}[t]
+\begin{figure}
\centering
- \includegraphics[width=.328\textwidth]{fig/cg_per}\hfill%
- \includegraphics[width=.328\textwidth]{fig/mg_pre}\hfill%
- % \includegraphics[width=.4\textwidth]{fig/bt_pre}\qquad%
- \includegraphics[width=.328\textwidth]{fig/lu_pre}\hfill%
- \caption{Comparing predicted to real execution time}
+ \includegraphics[width=.5\linewidth]{fig/cg_per}\hfill%
+ % \includegraphics[width=.5\linewidth]{fig/mg_pre}\hfill%
+ % \includegraphics[width=.5\linewidth]{fig/bt_pre}\qquad%
+ \includegraphics[width=.5\linewidth]{fig/lu_pre}\hfill%
+ \caption{Comparing predicted to real execution times}
\label{fig:pred}
-\end{figure*}
+\end{figure}
%see Figure~\ref{fig:pred}
In our cluster there are 18 available frequency states for each processor. This
leads to 18 run states for each program. We use seven MPI programs of the NAS
parallel benchmarks: CG, MG, EP, FT, BT, LU and SP. Figure~(\ref{fig:pred})
-presents plots of the real execution times and the simulated ones. The maximum
+presents plots of the real execution times and the simulated ones. The maximum
normalized error between these two execution times varies between \np{0.0073} to
\np{0.031} dependent on the executed benchmark. The smallest prediction error
was for CG and the worst one was for LU.
\subsection{The experimental results for the scaling algorithm }
-
The proposed algorithm was applied to seven MPI programs of the NAS benchmarks
(EP, CG, MG, FT, BT, LU and SP) which were run with three classes (A, B and C).
For each instance the benchmarks were executed on a number of processors
the two curves is very small. This leads to small energy savings. The opposite
happens when there are a lot of communication, the distance between the two
curves is big. This leads to more energy savings (e.g. CG and FT), see
-table~(\ref{table:factors results}). All discovered frequency scaling factors
+Table~(\ref{table:compareC}). All discovered frequency scaling factors
optimize both the energy and the performance simultaneously for all NAS
-benchmarks. In table~(\ref{table:factors results}), we record all optimal
+benchmarks. In Table~(\ref{table:compareC}), we record all optimal
scaling factors results for each benchmark running class C. These scaling
factors give the maximum energy saving percentage and the minimum performance
degradation percentage at the same time from all available scaling factors.
\begin{figure*}[t]
\centering
- \includegraphics[width=.328\textwidth]{fig/ep}\hfill%
- \includegraphics[width=.328\textwidth]{fig/cg}\hfill%
- \includegraphics[width=.328\textwidth]{fig/sp}
- \includegraphics[width=.328\textwidth]{fig/lu}\hfill%
- \includegraphics[width=.328\textwidth]{fig/bt}\hfill%
- \includegraphics[width=.328\textwidth]{fig/ft}
+ \includegraphics[width=.33\linewidth]{fig/ep}\hfill%
+ \includegraphics[width=.33\linewidth]{fig/cg}\hfill%
+ % \includegraphics[width=.328\linewidth]{fig/sp}
+ % \includegraphics[width=.328\linewidth]{fig/lu}\hfill%
+ \includegraphics[width=.33\linewidth]{fig/bt}
+ % \includegraphics[width=.328\linewidth]{fig/ft}
\caption{Optimal scaling factors for the predicted energy and performance of NAS benchmarks}
\label{fig:nas}
\end{figure*}
-\begin{table}[htb]
- \caption{The scaling factors results}
- % title of Table
- \centering
- \begin{tabular}{|l|*{4}{r|}}
- \hline
- Program & Optimal & Energy & Performance & Energy-Perf. \\
- Name & Scaling Factor & Saving \% & Degradation \% & Distance \\
- \hline
- CG & 1.56 & 39.23 & 14.88 & 24.35 \\
- \hline
- MG & 1.47 & 34.97 & 21.70 & 13.27 \\
- \hline
- EP & 1.04 & 22.14 & 20.73 & 1.41 \\
- \hline
- LU & 1.38 & 35.83 & 22.49 & 13.34 \\
- \hline
- BT & 1.31 & 29.60 & 21.28 & 8.32 \\
- \hline
- SP & 1.38 & 33.48 & 21.36 & 12.12 \\
- \hline
- FT & 1.47 & 34.72 & 19.00 & 15.72 \\
- \hline
- \end{tabular}
- \label{table:factors results}
- % is used to refer this table in the text
-\end{table}
-As shown in table~(\ref{table:factors results}), when the optimal scaling
+As shown in Table~(\ref{table:compareC}), when the optimal scaling
factor has a big value we can gain more energy savings as in CG and
-FT benchmarks. The opposite happens when the optimal scaling factor has a small value as in BT and EP benchmarks. Our algorithm selects a big scaling factor value when the
-communication and the other slacks times are big and smaller ones in opposite
-cases. In EP there are no communication inside the iterations. This leads our
-algorithm to select smaller scaling factor values (inducing smaller energy
+FT benchmarks. The opposite happens when the optimal scaling factor has a
+small value as in BT and EP benchmarks. Our algorithm selects a big scaling
+factor value when the communication and the other slacks times are big and smaller
+ones in opposite cases. In EP there are no communication inside the iterations.
+This leads our algorithm to select smaller scaling factor values (inducing smaller energy
savings).
\subsection{Results comparison}
(when the scale $S=1$) to keep the performance from degradation as mush as
possible. We refer to this scenario as $R_{E-P}$. While we refer to our
algorithm as EPSA (Energy to Performance Scaling Algorithm). The comparison is
-made in tables \ref{table:compareA}, \ref{table:compareB},
-and~\ref{table:compareC}. These tables show the results of our method and
-Rauber and Rünger scenarios for all the NAS benchmarks programs for classes A, B
-and C.
-\begin{table}[p]
- \caption{Comparing results for the NAS class A}
- % title of Table
- \centering
- \begin{tabular}{|l|l|*{4}{r|}}
- \hline
- Method & Program & Factor & Energy & Performance & Energy-Perf. \\
- Name & Name & Value & Saving \% & Degradation \% & Distance \\
- \hline
- % \rowcolor[gray]{0.85}
- $EPSA$ & CG & 1.56 & 37.02 & 13.88 & 23.14 \\ \hline
- $R_{E-P}$ & CG & 2.14 & 42.77 & 25.27 & 17.50 \\ \hline
- $R_{E}$ & CG & 2.14 & 42.77 & 26.46 & 16.31 \\ \hline
-
- $EPSA$ & MG & 1.47 & 27.66 & 16.82 & 10.84 \\ \hline
- $R_{E-P}$ & MG & 2.14 & 34.45 & 31.84 & 2.61 \\ \hline
- $R_{E}$ & MG & 2.14 & 34.48 & 33.65 & 0.80 \\ \hline
-
- $EPSA$ & EP & 1.19 & 25.32 & 20.79 & 4.53 \\ \hline
- $R_{E-P}$ & EP & 2.05 & 41.45 & 55.67 & -14.22 \\ \hline
- $R_{E}$ & EP & 2.05 & 42.09 & 57.59 & -15.50 \\ \hline
-
- $EPSA$ & LU & 1.56 & 39.55 & 19.38 & 20.17 \\ \hline
- $R_{E-P}$ & LU & 2.14 & 45.62 & 27.00 & 18.62 \\ \hline
- $R_{E}$ & LU & 2.14 & 45.66 & 33.01 & 12.65 \\ \hline
+made in Table ~\ref{table:compareC}. This table shows the results of our method and
+Rauber and Rünger scenarios for all the NAS benchmarks programs for class C.
- $EPSA$ & BT & 1.31 & 29.60 & 20.53 & 9.07 \\ \hline
- $R_{E-P}$ & BT & 2.10 & 45.53 & 49.63 & -4.10 \\ \hline
- $R_{E}$ & BT & 2.10 & 43.93 & 52.86 & -8.93 \\ \hline
-
- $EPSA$ & SP & 1.38 & 33.51 & 15.65 & 17.86 \\ \hline
- $R_{E-P}$ & SP & 2.11 & 45.62 & 42.52 & 3.10 \\ \hline
- $R_{E}$ & SP & 2.11 & 45.78 & 43.09 & 2.69 \\ \hline
-
- $EPSA$ & FT & 1.25 & 25.00 & 10.80 & 14.20 \\ \hline
- $R_{E-P}$ & FT & 2.10 & 39.29 & 34.30 & 4.99 \\ \hline
- $R_{E}$ & FT & 2.10 & 37.56 & 38.21 & -0.65 \\ \hline
- \end{tabular}
- \label{table:compareA}
- % is used to refer this table in the text
-\end{table}
-\begin{table}[p]
- \caption{Comparing results for the NAS class B}
- % title of Table
- \centering
- \begin{tabular}{|l|l|*{4}{r|}}
- \hline
- Method & Program & Factor & Energy & Performance & Energy-Perf. \\
- Name & Name & Value & Saving \% & Degradation \% & Distance \\
- \hline
- % \rowcolor[gray]{0.85}
- $EPSA$ & CG & 1.66 & 39.23 & 16.63 & 22.60 \\ \hline
- $R_{E-P}$ & CG & 2.15 & 45.34 & 27.60 & 17.74 \\ \hline
- $R_{E}$ & CG & 2.15 & 45.34 & 28.88 & 16.46 \\ \hline
-
- $EPSA$ & MG & 1.47 & 34.98 & 18.35 & 16.63 \\ \hline
- $R_{E-P}$ & MG & 2.14 & 43.55 & 36.42 & 7.13 \\ \hline
- $R_{E}$ & MG & 2.14 & 43.56 & 37.07 & 6.49 \\ \hline
-
- $EPSA$ & EP & 1.08 & 20.29 & 17.15 & 3.14 \\ \hline
- $R_{E-P}$ & EP & 2.00 & 42.38 & 56.88 & -14.50 \\ \hline
- $R_{E}$ & EP & 2.00 & 39.73 & 59.94 & -20.21 \\ \hline
-
- $EPSA$ & LU & 1.47 & 38.57 & 21.34 & 17.23 \\ \hline
- $R_{E-P}$ & LU & 2.10 & 43.62 & 36.51 & 7.11 \\ \hline
- $R_{E}$ & LU & 2.10 & 43.61 & 38.54 & 5.07 \\ \hline
-
- $EPSA$ & BT & 1.31 & 29.59 & 20.88 & 8.71 \\ \hline
- $R_{E-P}$ & BT & 2.10 & 44.53 & 53.05 & -8.52 \\ \hline
- $R_{E}$ & BT & 2.10 & 42.93 & 52.80 & -9.87 \\ \hline
-
- $EPSA$ & SP & 1.38 & 33.44 & 19.24 & 14.20 \\ \hline
- $R_{E-P}$ & SP & 2.15 & 45.69 & 43.20 & 2.49 \\ \hline
- $R_{E}$ & SP & 2.15 & 45.41 & 44.47 & 0.94 \\ \hline
-
- $EPSA$ & FT & 1.38 & 34.40 & 14.57 & 19.83 \\ \hline
- $R_{E-P}$ & FT & 2.13 & 42.98 & 37.35 & 5.63 \\ \hline
- $R_{E}$ & FT & 2.13 & 43.04 & 37.90 & 5.14 \\ \hline
- \end{tabular}
- \label{table:compareB}
- % is used to refer this table in the text
-\end{table}
-
-\begin{table}[p]
+\begin{table}
\caption{Comparing results for the NAS class C}
% title of Table
\centering
\begin{tabular}{|l|l|*{4}{r|}}
\hline
Method & Program & Factor & Energy & Performance & Energy-Perf. \\
- Name & Name & Value & Saving \% & Degradation \% & Distance \\
+ Name & Name & Value & Saving \% & Degradation \% & Distance \\
\hline
% \rowcolor[gray]{0.85}
$EPSA$ & CG & 1.56 & 39.23 & 14.88 & 24.35 \\ \hline
\label{table:compareC}
% is used to refer this table in the text
\end{table}
-As shown in tables~\ref{table:compareA},~\ref{table:compareB}
-and~\ref{table:compareC}, the ($R_{E-P}$) method outperforms the ($R_{E}$)
+As shown in Table~\ref{table:compareC}, the ($R_{E-P}$) method outperforms the ($R_{E}$)
method in terms of performance and energy reduction. The ($R_{E-P}$) method
also gives better energy savings than our method. However, although our scaling
-factor is not optimal for energy reduction, the results in these tables prove
+factor is not optimal for energy reduction, the results in this table prove
that our algorithm returns the best scaling factor that satisfy our objective
method: the largest distance between energy reduction and performance
-degradation. Figure~\ref{fig:compare} illustrates even better the distance between the energy reduction and performance degradation. The negative values mean that one of
+degradation. Figure~\ref{fig:compare} illustrates even better the distance between
+the energy reduction and performance degradation. The negative values mean that one of
the two objectives (energy or performance) have been degraded more than the
other. The positive trade-offs with the highest values lead to maximum energy
savings while keeping the performance degradation as low as possible. Our
algorithm always gives the highest positive energy to performance trade-offs
while Rauber and Rünger's method, ($R_{E-P}$), gives sometimes negative
trade-offs such as in BT and EP.
-\begin{figure*}[t]
+\begin{figure}[t]
\centering
- \includegraphics[width=.328\textwidth]{fig/compare_class_A}
- \includegraphics[width=.328\textwidth]{fig/compare_class_B}
- \includegraphics[width=.328\textwidth]{fig/compare_class_C}
+% \includegraphics[width=.328\linewidth]{fig/compare_class_A}
+% \includegraphics[width=.328\linewidth]{fig/compare_class_B}
+ \includegraphics[width=\linewidth]{fig/compare_class_C}
\caption{Comparing our method to Rauber and Rünger's methods}
\label{fig:compare}
-\end{figure*}
+\end{figure}
\section{Conclusion}
\label{sec.concl}
have applied it to the NAS benchmarks and it was compared to Rauber and Rünger
methods while being executed on the simulator SimGrid. The results showed that
our method, outperforms Rauber and Rünger's methods in terms of energy-performance
-ratio.
+ratio.
In the near future, we would like to adapt this scaling factor selection method
to heterogeneous platforms where each node has different characteristics. In
