]> AND Private Git Repository - mpi-energy2.git/blob - Heter_paper.tex
Logo AND Algorithmique Numérique Distribuée

Private GIT Repository
Merge branch 'master' of ssh://info.iut-bm.univ-fcomte.fr/mpi-energy2
[mpi-energy2.git] / Heter_paper.tex
1 \documentclass[conference]{IEEEtran}
2
3 \usepackage[T1]{fontenc}
4 \usepackage[utf8]{inputenc}
5 \usepackage[english]{babel}
6 \usepackage{algpseudocode}
7 \usepackage{graphicx}
8 \usepackage{algorithm}
9 \usepackage{subfig}
10 \usepackage{amsmath}
11 \usepackage{url}
12
13 \DeclareUrlCommand\email{\urlstyle{same}}
14
15 \usepackage[autolanguage,np]{numprint}
16 \AtBeginDocument{%
17   \renewcommand*\npunitcommand[1]{\text{#1}}
18   \npthousandthpartsep{}}
19
20 \usepackage{xspace}
21 \usepackage[textsize=footnotesize]{todonotes}
22 \newcommand{\AG}[2][inline]{%
23   \todo[color=green!50,#1]{\sffamily\textbf{AG:} #2}\xspace}
24 \newcommand{\JC}[2][inline]{%
25   \todo[color=red!10,#1]{\sffamily\textbf{JC:} #2}\xspace}
26
27 \newcommand{\Xsub}[2]{{\ensuremath{#1_\mathit{#2}}}}
28
29 %% used to put some subscripts lower, and make them more legible
30 \newcommand{\fxheight}[1]{\ifx#1\relax\relax\else\rule{0pt}{1.52ex}#1\fi}
31
32 \newcommand{\CL}{\Xsub{C}{L}}
33 \newcommand{\Dist}{\mathit{Dist}}
34 \newcommand{\EdNew}{\Xsub{E}{dNew}}
35 \newcommand{\Eind}{\Xsub{E}{ind}}
36 \newcommand{\Enorm}{\Xsub{E}{Norm}}
37 \newcommand{\Eoriginal}{\Xsub{E}{Original}}
38 \newcommand{\Ereduced}{\Xsub{E}{Reduced}}
39 \newcommand{\Es}{\Xsub{E}{S}}
40 \newcommand{\Fdiff}[1][]{\Xsub{F}{diff}_{\!#1}}
41 \newcommand{\Fmax}[1][]{\Xsub{F}{max}_{\fxheight{#1}}}
42 \newcommand{\Fnew}{\Xsub{F}{new}}
43 \newcommand{\Ileak}{\Xsub{I}{leak}}
44 \newcommand{\Kdesign}{\Xsub{K}{design}}
45 \newcommand{\MaxDist}{\mathit{Max}\Dist}
46 \newcommand{\MinTcm}{\mathit{Min}\Tcm}
47 \newcommand{\Ntrans}{\Xsub{N}{trans}}
48 \newcommand{\Pd}[1][]{\Xsub{P}{d}_{\fxheight{#1}}}
49 \newcommand{\PdNew}{\Xsub{P}{dNew}}
50 \newcommand{\PdOld}{\Xsub{P}{dOld}}
51 \newcommand{\Pnorm}{\Xsub{P}{Norm}}
52 \newcommand{\Ps}[1][]{\Xsub{P}{s}_{\fxheight{#1}}}
53 \newcommand{\Scp}[1][]{\Xsub{S}{cp}_{#1}}
54 \newcommand{\Sopt}[1][]{\Xsub{S}{opt}_{#1}}
55 \newcommand{\Tcm}[1][]{\Xsub{T}{cm}_{\fxheight{#1}}}
56 \newcommand{\Tcp}[1][]{\Xsub{T}{cp}_{#1}}
57 \newcommand{\TcpOld}[1][]{\Xsub{T}{cpOld}_{#1}}
58 \newcommand{\Tnew}{\Xsub{T}{New}}
59 \newcommand{\Told}{\Xsub{T}{Old}}
60
61 \begin{document}
62
63 \title{Energy Consumption Reduction with DVFS for \\
64   Message Passing Iterative Applications on \\
65   Heterogeneous Architectures}
66
67 \author{%
68   \IEEEauthorblockN{%
69     Jean-Claude Charr,
70     Raphaël Couturier,
71     Ahmed Fanfakh and
72     Arnaud Giersch
73   }
74   \IEEEauthorblockA{%
75     FEMTO-ST Institute, University of Franche-Comté\\
76     IUT de Belfort-Montbéliard,
77     19 avenue du Maréchal Juin, BP 527, 90016 Belfort cedex, France\\
78     % Telephone: \mbox{+33 3 84 58 77 86}, % Raphaël
79     % Fax: \mbox{+33 3 84 58 77 81}\\      % Dept Info
80     Email: \email{{jean-claude.charr,raphael.couturier,ahmed.fanfakh_badri_muslim,arnaud.giersch}@univ-fcomte.fr}
81    }
82   }
83
84 \maketitle
85
86 \begin{abstract}
87   Computing platforms are consuming more and more energy due to the increasing
88   number of nodes composing them.  To minimize the operating costs of these
89   platforms many techniques have been used. Dynamic voltage and frequency
90   scaling (DVFS) is one of them. It reduces the frequency of a CPU to lower its
91   energy consumption.  However, lowering the frequency of a CPU may increase
92   the execution time of an application running on that processor.  Therefore,
93   the frequency that gives the best trade-off between the energy consumption and
94   the performance of an application must be selected.
95
96   In this paper, a new online frequency selecting algorithm for heterogeneous
97   platforms (heterogeneous CPUs) is presented.  It selects the frequencies and tries to give the best
98   trade-off between energy saving and performance degradation, for each node
99   computing the message passing iterative application. The algorithm has a small
100   overhead and works without training or profiling. It uses a new energy model
101   for message passing iterative applications running on a heterogeneous
102   platform. The proposed algorithm is evaluated on the SimGrid simulator while
103   running the NAS parallel benchmarks.  The experiments show that it reduces the
104   energy consumption by up to \np[\%]{34} while limiting the performance
105   degradation as much as possible.  Finally, the algorithm is compared to an
106   existing method, the comparison results show that it outperforms the
107   latter, on average it saves \np[\%]{4} more energy while keeping the same performance. 
108
109 \end{abstract}
110
111 \section{Introduction}
112 \label{sec.intro}
113
114 The need for more computing power is continually increasing. To partially
115 satisfy this need, most supercomputers constructors just put more computing
116 nodes in their platform. The resulting platforms may achieve higher floating
117 point operations per second (FLOPS), but the energy consumption and the heat
118 dissipation are also increased.  As an example, the Chinese supercomputer
119 Tianhe-2 had the highest FLOPS in November 2014 according to the Top500 list
120 \cite{TOP500_Supercomputers_Sites}.  However, it was also the most power hungry
121 platform with its over 3 million cores consuming around 17.8 megawatts.
122 Moreover, according to the U.S.  annual energy outlook 2014
123 \cite{U.S_Annual.Energy.Outlook.2014}, the price of energy for 1 megawatt-hour
124 was approximately equal to \$70.  Therefore, the price of the energy consumed by
125 the Tianhe-2 platform is approximately more than \$10 million each year.  The
126 computing platforms must be more energy efficient and offer the highest number
127 of FLOPS per watt possible, such as the L-CSC from the GSI Helmholtz Center
128 which became the top of the Green500 list in November 2014 \cite{Green500_List}.
129 This heterogeneous platform executes more than 5 GFLOPS per watt while consuming
130 57.15 kilowatts.
131
132 Besides platform improvements, there are many software and hardware techniques
133 to lower the energy consumption of these platforms, such as scheduling, DVFS,
134 \dots{} DVFS is a widely used process to reduce the energy consumption of a
135 processor by lowering its frequency
136 \cite{Rizvandi_Some.Observations.on.Optimal.Frequency}. However, it also reduces
137 the number of FLOPS executed by the processor which may increase the execution
138 time of the application running over that processor.  Therefore, researchers use
139 different optimization strategies to select the frequency that gives the best
140 trade-off between the energy reduction and performance degradation ratio. In
141 \cite{Our_first_paper}, a frequency selecting algorithm was proposed to reduce
142 the energy consumption of message passing iterative applications running over
143 homogeneous platforms.  The results of the experiments show significant energy
144 consumption reductions. In this paper, a new frequency selecting algorithm
145 adapted for heterogeneous platform is presented. It selects the vector of
146 frequencies, for a heterogeneous platform running a message passing iterative
147 application, that simultaneously tries to offer the maximum energy reduction and
148 minimum performance degradation ratio. The algorithm has a very small overhead,
149 works online and does not need any training or profiling.
150
151 This paper is organized as follows: Section~\ref{sec.relwork} presents some
152 related works from other authors.  Section~\ref{sec.exe} describes how the
153 execution time of message passing programs can be predicted.  It also presents
154 an energy model that predicts the energy consumption of an application running
155 over a heterogeneous platform. Section~\ref{sec.compet} presents the
156 energy-performance objective function that maximizes the reduction of energy
157 consumption while minimizing the degradation of the program's performance.
158 Section~\ref{sec.optim} details the proposed frequency selecting algorithm then
159 the precision of the proposed algorithm is verified.  Section~\ref{sec.expe}
160 presents the results of applying the algorithm on the NAS parallel benchmarks
161 and executing them on a heterogeneous platform. It shows the results of running
162 three different power scenarios and comparing them. Moreover, it also shows the
163 comparison results between the proposed method and an existing method.  Finally,
164 in Section~\ref{sec.concl} the paper ends with a summary and some future works.
165
166 \section{Related works}
167 \label{sec.relwork}
168
169 DVFS is a technique used in modern processors to scale down both the voltage and
170 the frequency of the CPU while computing, in order to reduce the energy
171 consumption of the processor. DVFS is also allowed in GPUs to achieve the same
172 goal. Reducing the frequency of a processor lowers its number of FLOPS and may
173 degrade the performance of the application running on that processor, especially
174 if it is compute bound. Therefore selecting the appropriate frequency for a
175 processor to satisfy some objectives, while taking into account all the
176 constraints, is not a trivial operation.  Many researchers used different
177 strategies to tackle this problem. Some of them developed online methods that
178 compute the new frequency while executing the application, such
179 as~\cite{Hao_Learning.based.DVFS,Spiliopoulos_Green.governors.Adaptive.DVFS}.
180 Others used offline methods that may need to run the application and profile
181 it before selecting the new frequency, such
182 as~\cite{Rountree_Bounding.energy.consumption.in.MPI,Cochran_Pack_and_Cap_Adaptive_DVFS}.
183 The methods could be heuristics, exact or brute force methods that satisfy
184 varied objectives such as energy reduction or performance. They also could be
185 adapted to the execution's environment and the type of the application such as
186 sequential, parallel or distributed architecture, homogeneous or heterogeneous
187 platform, synchronous or asynchronous application, \dots{}
188
189 In this paper, we are interested in reducing energy for message passing
190 iterative synchronous applications running over heterogeneous platforms.  Some
191 works have already been done for such platforms and they can be classified into
192 two types of heterogeneous platforms:
193 \begin{itemize}
194 \item the platform is composed of homogeneous GPUs and homogeneous CPUs.
195 \item the platform is only composed of heterogeneous CPUs.
196 \end{itemize}
197
198 For the first type of platform, the computing intensive parallel tasks are
199 executed on the GPUs and the rest are executed on the CPUs.  Luley et
200 al.~\cite{Luley_Energy.efficiency.evaluation.and.benchmarking}, proposed a
201 heterogeneous cluster composed of Intel Xeon CPUs and NVIDIA GPUs. Their main
202 goal was to maximize the energy efficiency of the platform during computation by
203 maximizing the number of FLOPS per watt generated.
204 In~\cite{KaiMa_Holistic.Approach.to.Energy.Efficiency.in.GPU-CPU}, Kai Ma et
205 al. developed a scheduling algorithm that distributes workloads proportional to
206 the computing power of the nodes which could be a GPU or a CPU. All the tasks
207 must be completed at the same time.  In~\cite{Rong_Effects.of.DVFS.on.K20.GPU},
208 Rong et al. showed that a heterogeneous (GPUs and CPUs) cluster that enables
209 DVFS gave better energy and performance efficiency than other clusters only
210 composed of CPUs.
211
212 The work presented in this paper concerns the second type of platform, with
213 heterogeneous CPUs.  Many methods were conceived to reduce the energy
214 consumption of this type of platform.  Naveen et
215 al.~\cite{Naveen_Power.Efficient.Resource.Scaling} developed a method that
216 minimizes the value of $\mathit{energy}\times \mathit{delay}^2$ (the delay is
217 the sum of slack times that happen during synchronous communications) by
218 dynamically assigning new frequencies to the CPUs of the heterogeneous cluster.
219 Lizhe et al.~\cite{Lizhe_Energy.aware.parallel.task.scheduling} proposed an
220 algorithm that divides the executed tasks into two types: the critical and non
221 critical tasks. The algorithm scales down the frequency of non critical tasks
222 proportionally to their slack and communication times while limiting the
223 performance degradation percentage to less than \np[\%]{10}.
224 In~\cite{Joshi_Blackbox.prediction.of.impact.of.DVFS}, they developed a
225 heterogeneous cluster composed of two types of Intel and AMD processors. They
226 use a gradient method to predict the impact of DVFS operations on performance.
227 In~\cite{Shelepov_Scheduling.on.Heterogeneous.Multicore} and
228 \cite{Li_Minimizing.Energy.Consumption.for.Frame.Based.Tasks}, the best
229 frequencies for a specified heterogeneous cluster are selected offline using
230 some heuristic.  Chen et
231 al.~\cite{Chen_DVFS.under.quality.of.service.requirements} used a greedy dynamic
232 programming approach to minimize the power consumption of heterogeneous servers
233 while respecting given time constraints.  This approach had considerable
234 overhead.  In contrast to the above described papers, this paper presents the
235 following contributions :
236 \begin{enumerate}
237 \item two new energy and performance models for message passing iterative
238   synchronous applications running over a heterogeneous platform. Both models
239   take into account communication and slack times. The models can predict the
240   required energy and the execution time of the application.
241
242 \item a new online frequency selecting algorithm for heterogeneous
243   platforms. The algorithm has a very small overhead and does not need any
244   training or profiling. It uses a new optimization function which
245   simultaneously maximizes the performance and minimizes the energy consumption
246   of a message passing iterative synchronous application.
247
248 \end{enumerate}
249
250 \section{The performance and energy consumption measurements on heterogeneous architecture}
251 \label{sec.exe}
252
253 \subsection{The execution time of message passing distributed iterative
254   applications on a heterogeneous platform}
255
256 In this paper, we are interested in reducing the energy consumption of message
257 passing distributed iterative synchronous applications running over
258 heterogeneous platforms. A heterogeneous platform is defined as a collection of
259 heterogeneous computing nodes interconnected via a high speed homogeneous
260 network. Therefore, each node has different characteristics such as computing
261 power (FLOPS), energy consumption, CPU's frequency range, \dots{} but they all
262 have the same network bandwidth and latency.
263
264 \begin{figure}[!t]
265   \centering
266   \includegraphics[scale=0.6]{fig/commtasks}
267   \caption{Parallel tasks on a heterogeneous platform}
268   \label{fig:heter}
269 \end{figure}
270
271 The overall execution time of a distributed iterative synchronous application
272 over a heterogeneous platform consists of the sum of the computation time and
273 the communication time for every iteration on a node. However, due to the
274 heterogeneous computation power of the computing nodes, slack times may occur
275 when fast nodes have to wait, during synchronous communications, for the slower
276 nodes to finish their computations (see Figure~\ref{fig:heter}).  Therefore, the
277 overall execution time of the program is the execution time of the slowest task
278 which has the highest computation time and no slack time.
279
280 Dynamic Voltage and Frequency Scaling (DVFS) is a process, implemented in
281 modern processors, that reduces the energy consumption of a CPU by scaling
282 down its voltage and frequency.  Since DVFS lowers the frequency of a CPU
283 and consequently its computing power, the execution time of a program running
284 over that scaled down processor may increase, especially if the program is
285 compute bound.  The frequency reduction process can be  expressed by the scaling
286 factor S which is the ratio between  the maximum and the new frequency of a CPU
287 as in (\ref{eq:s}).
288 \begin{equation}
289   \label{eq:s}
290   S = \frac{\Fmax}{\Fnew}
291 \end{equation}
292 The execution time of a compute bound sequential program is linearly
293 proportional to the frequency scaling factor $S$.  On the other hand, message
294 passing distributed applications consist of two parts: computation and
295 communication.  The execution time of the computation part is linearly
296 proportional to the frequency scaling factor $S$ but the communication time is
297 not affected by the scaling factor because the processors involved remain idle
298 during the communications~\cite{Freeh_Exploring.the.Energy.Time.Tradeoff}.  The
299 communication time for a task is the summation of periods of time that begin
300 with an MPI call for sending or receiving a message until the message is
301 synchronously sent or received.
302
303 Since in a heterogeneous platform each node has different characteristics,
304 especially different frequency gears, when applying DVFS operations on these
305 nodes, they may get different scaling factors represented by a scaling vector:
306 $(S_1, S_2,\dots, S_N)$ where $S_i$ is the scaling factor of processor $i$. To
307 be able to predict the execution time of message passing synchronous iterative
308 applications running over a heterogeneous platform, for different vectors of
309 scaling factors, the communication time and the computation time for all the
310 tasks must be measured during the first iteration before applying any DVFS
311 operation. Then the execution time for one iteration of the application with any
312 vector of scaling factors can be predicted using (\ref{eq:perf}).
313 \begin{equation}
314   \label{eq:perf}
315   \Tnew = \max_{i=1,2,\dots,N} ({\TcpOld[i]} \cdot S_{i}) +  \MinTcm
316 \end{equation}
317 Where:
318 \begin{equation}
319   \label{eq:perf2}
320   \MinTcm = \min_{i=1,2,\dots,N} (\Tcm[i])
321 \end{equation}
322 where $\TcpOld[i]$ is the computation time of processor $i$ during the first
323 iteration and $\MinTcm$ is the communication time of the slowest processor from
324 the first iteration.  The model computes the maximum computation time with
325 scaling factor from each node added to the communication time of the slowest
326 node. It means only the communication time without any slack time is taken into
327 account.  Therefore, the execution time of the iterative application is equal to
328 the execution time of one iteration as in (\ref{eq:perf}) multiplied by the
329 number of iterations of that application.
330
331 This prediction model is developed from the model to predict the execution time
332 of message passing distributed applications for homogeneous
333 architectures~\cite{Our_first_paper}.  The execution time prediction model is
334 used in the method to optimize both the energy consumption and the performance
335 of iterative methods, which is presented in the following sections.
336
337 \subsection{Energy model for heterogeneous platform}
338
339 Many researchers~\cite{Malkowski_energy.efficient.high.performance.computing,
340   Rauber_Analytical.Modeling.for.Energy,Zhuo_Energy.efficient.Dynamic.Task.Scheduling,
341   Rizvandi_Some.Observations.on.Optimal.Frequency} divide the power consumed by
342 a processor into two power metrics: the static and the dynamic power.  While the
343 first one is consumed as long as the computing unit is turned on, the latter is
344 only consumed during computation times.  The dynamic power $\Pd$ is related to
345 the switching activity $\alpha$, load capacitance $\CL$, the supply voltage $V$
346 and operational frequency $F$, as shown in (\ref{eq:pd}).
347 \begin{equation}
348   \label{eq:pd}
349   \Pd = \alpha \cdot \CL \cdot V^2 \cdot F
350 \end{equation}
351 The static power $\Ps$ captures the leakage power as follows:
352 \begin{equation}
353   \label{eq:ps}
354    \Ps  = V \cdot \Ntrans \cdot \Kdesign \cdot \Ileak
355 \end{equation}
356 where V is the supply voltage, $\Ntrans$ is the number of transistors,
357 $\Kdesign$ is a design dependent parameter and $\Ileak$ is a
358 technology dependent parameter.  The energy consumed by an individual processor
359 to execute a given program can be computed as:
360 \begin{equation}
361   \label{eq:eind}
362   \Eind =  \Pd \cdot \Tcp + \Ps \cdot T
363 \end{equation}
364 where $T$ is the execution time of the program, $\Tcp$ is the computation
365 time and $\Tcp \le T$.  $\Tcp$ may be equal to $T$ if there is no
366 communication and no slack time.
367
368 The main objective of DVFS operation is to reduce the overall energy
369 consumption~\cite{Le_DVFS.Laws.of.Diminishing.Returns}.  The operational
370 frequency $F$ depends linearly on the supply voltage $V$, i.e., $V = \beta \cdot
371 F$ with some constant $\beta$.~This equation is used to study the change of the
372 dynamic voltage with respect to various frequency values
373 in~\cite{Rauber_Analytical.Modeling.for.Energy}.  The reduction process of the
374 frequency can be expressed by the scaling factor $S$ which is the ratio between
375 the maximum and the new frequency as in (\ref{eq:s}).  The CPU governors are
376 power schemes supplied by the operating system's kernel to lower a core's
377 frequency. The new frequency $\Fnew$ from (\ref{eq:s}) can be calculated as
378 follows:
379 \begin{equation}
380   \label{eq:fnew}
381    \Fnew = S^{-1} \cdot \Fmax
382 \end{equation}
383 Replacing $\Fnew$ in (\ref{eq:pd}) as in (\ref{eq:fnew}) gives the following
384 equation for dynamic power consumption:
385 \begin{multline}
386   \label{eq:pdnew}
387    \PdNew = \alpha \cdot \CL \cdot V^2 \cdot \Fnew = \alpha \cdot \CL \cdot \beta^2 \cdot \Fnew^3 \\
388    {} = \alpha \cdot \CL \cdot V^2 \cdot \Fmax \cdot S^{-3} = \PdOld \cdot S^{-3}
389 \end{multline}
390 where $\PdNew$  and $\PdOld$ are the  dynamic power consumed with the
391 new frequency and the maximum frequency respectively.
392
393 According to (\ref{eq:pdnew}) the dynamic power is reduced by a factor of
394 $S^{-3}$ when reducing the frequency by a factor of
395 $S$~\cite{Rauber_Analytical.Modeling.for.Energy}. Since the FLOPS of a CPU is
396 proportional to the frequency of a CPU, the computation time is increased
397 proportionally to $S$.  The new dynamic energy is the dynamic power multiplied
398 by the new time of computation and is given by the following equation:
399 \begin{equation}
400   \label{eq:Edyn}
401    \EdNew = \PdOld \cdot S^{-3} \cdot (\Tcp \cdot S)= S^{-2}\cdot \PdOld \cdot  \Tcp
402 \end{equation}
403 The static power is related to the power leakage of the CPU and is consumed
404 during computation and even when idle. As
405 in~\cite{Rauber_Analytical.Modeling.for.Energy,Zhuo_Energy.efficient.Dynamic.Task.Scheduling},
406 the static power of a processor is considered as constant during idle and
407 computation periods, and for all its available frequencies.  The static energy
408 is the static power multiplied by the execution time of the program.  According
409 to the execution time model in (\ref{eq:perf}), the execution time of the
410 program is the sum of the computation and the communication times. The
411 computation time is linearly related to the frequency scaling factor, while this
412 scaling factor does not affect the communication time.  The static energy of a
413 processor after scaling its frequency is computed as follows:
414 \begin{equation}
415   \label{eq:Estatic}
416   \Es = \Ps \cdot (\Tcp \cdot S  + \Tcm)
417 \end{equation}
418
419 In the considered heterogeneous platform, each processor $i$ may have
420 different dynamic and static powers, noted as $\Pd[i]$ and $\Ps[i]$
421 respectively.  Therefore, even if the distributed message passing iterative
422 application is load balanced, the computation time of each CPU $i$ noted
423 $\Tcp[i]$ may be different and different frequency scaling factors may be
424 computed in order to decrease the overall energy consumption of the application
425 and reduce slack times.  The communication time of a processor $i$ is noted as
426 $\Tcm[i]$ and could contain slack times when communicating with slower nodes,
427 see Figure~\ref{fig:heter}.  Therefore, all nodes do not have equal
428 communication times. While the dynamic energy is computed according to the
429 frequency scaling factor and the dynamic power of each node as in
430 (\ref{eq:Edyn}), the static energy is computed as the sum of the execution time
431 of one iteration multiplied by the static power of each processor.  The overall
432 energy consumption of a message passing distributed application executed over a
433 heterogeneous platform during one iteration is the summation of all dynamic and
434 static energies for each processor.  It is computed as follows:
435 \begin{multline}
436   \label{eq:energy}
437  E = \sum_{i=1}^{N} {(S_i^{-2} \cdot \Pd[i] \cdot  \Tcp[i])} + {} \\
438  \sum_{i=1}^{N} (\Ps[i] \cdot (\max_{i=1,2,\dots,N} (\Tcp[i] \cdot S_{i}) +
439   {\MinTcm))}
440 \end{multline}
441
442 Reducing the frequencies of the processors according to the vector of scaling
443 factors $(S_1, S_2,\dots, S_N)$ may degrade the performance of the application
444 and thus, increase the static energy because the execution time is
445 increased~\cite{Kim_Leakage.Current.Moore.Law}. The overall energy consumption
446 for the iterative application can be measured by measuring the energy
447 consumption for one iteration as in (\ref{eq:energy}) multiplied by the number
448 of iterations of that application.
449
450 \section{Optimization of both energy consumption and performance}
451 \label{sec.compet}
452
453 Using the lowest frequency for each processor does not necessarily give the most
454 energy efficient execution of an application. Indeed, even though the dynamic
455 power is reduced while scaling down the frequency of a processor, its
456 computation power is proportionally decreased. Hence, the execution time might
457 be drastically increased and during that time, dynamic and static powers are
458 being consumed.  Therefore, it might cancel any gains achieved by scaling down
459 the frequency of all nodes to the minimum and the overall energy consumption of
460 the application might not be the optimal one.  It is not trivial to select the
461 appropriate frequency scaling factor for each processor while considering the
462 characteristics of each processor (computation power, range of frequencies,
463 dynamic and static powers) and the task executed (computation/communication
464 ratio). The aim being to reduce the overall energy consumption and to avoid
465 increasing significantly the execution time.  In our previous
466 work~\cite{Our_first_paper}, we proposed a method that selects the optimal
467 frequency scaling factor for a homogeneous cluster executing a message passing
468 iterative synchronous application while giving the best trade-off between the
469 energy consumption and the performance for such applications.  In this work we
470 are interested in heterogeneous clusters as described above.  Due to the
471 heterogeneity of the processors, a vector of scaling factors should be selected
472 and it must give the best trade-off between energy consumption and performance.
473
474 The relation between the energy consumption and the execution time for an
475 application is complex and nonlinear, Thus, unlike the relation between the
476 execution time and the scaling factor, the relation between the energy and the
477 frequency scaling factors is nonlinear, for more details refer
478 to~\cite{Freeh_Exploring.the.Energy.Time.Tradeoff}.  Moreover, these relations
479 are not measured using the same metric.  To solve this problem, the execution
480 time is normalized by computing the ratio between the new execution time (after
481 scaling down the frequencies of some processors) and the initial one (with
482 maximum frequency for all nodes) as follows:
483 \begin{multline}
484   \label{eq:pnorm}
485   \Pnorm = \frac{\Tnew}{\Told}\\
486        {} = \frac{ \max_{i=1,2,\dots,N} (\Tcp[i] \cdot S_{i}) +\MinTcm}
487            {\max_{i=1,2,\dots,N}{(\Tcp[i]+\Tcm[i])}}
488 \end{multline}
489
490 In the same way, the energy is normalized by computing the ratio between the
491 consumed energy while scaling down the frequency and the consumed energy with
492 maximum frequency for all nodes:
493 \begin{multline}
494   \label{eq:enorm}
495   \Enorm = \frac{\Ereduced}{\Eoriginal} \\
496   {} = \frac{ \sum_{i=1}^{N}{(S_i^{-2} \cdot \Pd[i] \cdot  \Tcp[i])} +
497  \sum_{i=1}^{N} {(\Ps[i] \cdot \Tnew)}}{\sum_{i=1}^{N}{( \Pd[i] \cdot  \Tcp[i])} +
498  \sum_{i=1}^{N} {(\Ps[i] \cdot \Told)}}
499 \end{multline}
500 Where $\Ereduced$ and $\Eoriginal$ are computed using (\ref{eq:energy}) and
501 $\Tnew$ and $\Told$ are computed as in (\ref{eq:pnorm}).
502
503 While the main goal is to optimize the energy and execution time at the same
504 time, the normalized energy and execution time curves do not evolve (increase/decrease) in the same way. According to the equations~(\ref{eq:pnorm}) and (\ref{eq:enorm}), the
505 vector of frequency scaling factors $S_1,S_2,\dots,S_N$ reduce both the energy
506 and the execution time simultaneously.  But the main objective is to produce
507 maximum energy reduction with minimum execution time reduction.
508
509 This problem can be solved by making the optimization process for energy and
510 execution time follow the same evolution according to the vector of scaling factors. Therefore, the equation of the
511 normalized execution time is inverted which gives the normalized performance
512 equation, as follows:
513 \begin{multline}
514   \label{eq:pnorm_inv}
515   \Pnorm = \frac{\Told}{\Tnew}\\
516           = \frac{\max_{i=1,2,\dots,N}{(\Tcp[i]+\Tcm[i])}}
517             { \max_{i=1,2,\dots,N} (\Tcp[i] \cdot S_{i}) + \MinTcm}
518 \end{multline}
519
520 \begin{figure}[!t]
521   \centering
522   \subfloat[Homogeneous platform]{%
523     \includegraphics[width=.33\textwidth]{fig/homo}\label{fig:r1}}%
524
525   \subfloat[Heterogeneous platform]{%
526     \includegraphics[width=.33\textwidth]{fig/heter}\label{fig:r2}}
527   \label{fig:rel}
528   \caption{The energy and performance relation}
529 \end{figure}
530
531 Then, the objective function can be modeled in order to find the maximum
532 distance between the energy curve (\ref{eq:enorm}) and the performance curve
533 (\ref{eq:pnorm_inv}) over all available sets of scaling factors.  This
534 represents the minimum energy consumption with minimum execution time (maximum
535 performance) at the same time, see Figure~\ref{fig:r1} or
536 Figure~\ref{fig:r2}. Then the objective function has the following form:
537 \begin{equation}
538   \label{eq:max}
539   \MaxDist =
540   \mathop{\max_{i=1,\dots F}}_{j=1,\dots,N}
541       (\overbrace{\Pnorm(S_{ij})}^{\text{Maximize}} -
542        \overbrace{\Enorm(S_{ij})}^{\text{Minimize}} )
543 \end{equation}
544 where $N$ is the number of nodes and $F$ is the number of available frequencies
545 for each node.  Then, the optimal set of scaling factors that satisfies
546 (\ref{eq:max}) can be selected.  The objective function can work with any energy
547 model or any power values for each node (static and dynamic powers). However,
548 the most important energy reduction gain can be achieved when the energy curve
549 has a convex form as shown
550 in~\cite{Zhuo_Energy.efficient.Dynamic.Task.Scheduling,Rauber_Analytical.Modeling.for.Energy,Hao_Learning.based.DVFS}.
551
552 \section{The scaling factors selection algorithm for heterogeneous platforms }
553 \label{sec.optim}
554
555 \begin{algorithm}
556   \begin{algorithmic}[1]
557     % \footnotesize
558     \Require ~
559     \begin{description}
560     \item[{$\Tcp[i]$}] array of all computation times for all nodes during one iteration and with highest frequency.
561     \item[{$\Tcm[i]$}] array of all communication times for all nodes during one iteration and with highest frequency.
562     \item[{$\Fmax[i]$}] array of the maximum frequencies for all nodes.
563     \item[{$\Pd[i]$}] array of the dynamic powers for all nodes.
564     \item[{$\Ps[i]$}] array of the static powers for all nodes.
565     \item[{$\Fdiff[i]$}] array of the differences between two successive frequencies for all nodes.
566     \end{description}
567     \Ensure $\Sopt[1],\Sopt[2] \dots, \Sopt[N]$ is a vector of optimal scaling factors
568
569     \State $\Scp[i] \gets \frac{\max_{i=1,2,\dots,N}(\Tcp[i])}{\Tcp[i]} $
570     \State $F_{i} \gets  \frac{\Fmax[i]}{\Scp[i]},~{i=1,2,\cdots,N}$
571     \State Round the computed initial frequencies $F_i$ to the closest one available in each node.
572     \If{(not the first frequency)}
573           \State $F_i \gets F_i+\Fdiff[i],~i=1,\dots,N.$
574     \EndIf
575     \State $\Told \gets \max_{i=1,\dots,N} (\Tcp[i]+\Tcm[i])$
576     % \State $\Eoriginal \gets \sum_{i=1}^{N}{( \Pd[i] \cdot  \Tcp[i])} +\sum_{i=1}^{N} {(\Ps[i] \cdot \Told)}$
577     \State $\Eoriginal \gets \sum_{i=1}^{N}{( \Pd[i] \cdot  \Tcp[i] + \Ps[i] \cdot \Told)}$
578     \State $\Sopt[i] \gets 1,~i=1,\dots,N. $
579     \State $\Dist \gets 0 $
580     \While {(all nodes not reach their  minimum  frequency)}
581         \If{(not the last freq. \textbf{and} not the slowest node)}
582         \State $F_i \gets F_i - \Fdiff[i],~i=1,\dots,N.$
583         \State $S_i \gets \frac{\Fmax[i]}{F_i},~i=1,\dots,N.$
584         \EndIf
585        \State $\Tnew \gets \max_{i=1,\dots,N} (\Tcp[i] \cdot S_{i}) + \MinTcm $
586 %       \State $\Ereduced \gets \sum_{i=1}^{N}{(S_i^{-2} \cdot \Pd[i] \cdot  \Tcp[i])} + \sum_{i=1}^{N} {(\Ps[i] \cdot \rlap{\Tnew)}} $
587        \State $\Ereduced \gets \sum_{i=1}^{N}{(S_i^{-2} \cdot \Pd[i] \cdot  \Tcp[i] + \Ps[i] \cdot \rlap{\Tnew)}} $
588        \State $\Pnorm \gets \frac{\Told}{\Tnew}$
589        \State $\Enorm\gets \frac{\Ereduced}{\Eoriginal}$
590       \If{$(\Pnorm - \Enorm > \Dist)$}
591         \State $\Sopt[i] \gets S_{i},~i=1,\dots,N. $
592         \State $\Dist \gets \Pnorm - \Enorm$
593       \EndIf
594     \EndWhile
595     \State  Return $\Sopt[1],\Sopt[2],\dots,\Sopt[N]$
596   \end{algorithmic}
597   \caption{frequency scaling factors selection algorithm}
598   \label{HSA}
599 \end{algorithm}
600
601 \begin{algorithm}
602   \begin{algorithmic}[1]
603     % \footnotesize
604     \For {$k=1$ to \textit{some iterations}}
605       \State Computations section.
606       \State Communications section.
607       \If {$(k=1)$}
608         \State Gather all times of computation and\newline\hspace*{3em}%
609                communication from each node.
610         \State Call Algorithm \ref{HSA}.
611         \State Compute the new frequencies from the\newline\hspace*{3em}%
612                returned optimal scaling factors.
613         \State Set the new frequencies to nodes.
614       \EndIf
615     \EndFor
616   \end{algorithmic}
617   \caption{DVFS algorithm}
618   \label{dvfs}
619 \end{algorithm}
620
621 \subsection{The algorithm details}
622
623 In this section, Algorithm~\ref{HSA} is presented. It selects the frequency
624 scaling factors vector that gives the best trade-off between minimizing the
625 energy consumption and maximizing the performance of a message passing
626 synchronous iterative application executed on a heterogeneous platform. It works
627 online during the execution time of the iterative message passing program.  It
628 uses information gathered during the first iteration such as the computation
629 time and the communication time in one iteration for each node. The algorithm is
630 executed after the first iteration and returns a vector of optimal frequency
631 scaling factors that satisfies the objective function (\ref{eq:max}). The
632 program applies DVFS operations to change the frequencies of the CPUs according
633 to the computed scaling factors.  This algorithm is called just once during the
634 execution of the program. Algorithm~\ref{dvfs} shows where and when the proposed
635 scaling algorithm is called in the iterative MPI program.
636
637 \begin{figure}[!t]
638   \centering
639   \includegraphics[scale=0.5]{fig/start_freq}
640   \caption{Selecting the initial frequencies}
641   \label{fig:st_freq}
642 \end{figure}
643
644 The nodes in a heterogeneous platform have different computing powers, thus
645 while executing message passing iterative synchronous applications, fast nodes
646 have to wait for the slower ones to finish their computations before being able
647 to synchronously communicate with them as in Figure~\ref{fig:heter}.  These
648 periods are called idle or slack times.  The algorithm takes into account this
649 problem and tries to reduce these slack times when selecting the frequency
650 scaling factors vector. At first, it selects initial frequency scaling factors
651 that increase the execution times of fast nodes and minimize the differences
652 between the computation times of fast and slow nodes. The value of the initial
653 frequency scaling factor for each node is inversely proportional to its
654 computation time that was gathered from the first iteration. These initial
655 frequency scaling factors are computed as a ratio between the computation time
656 of the slowest node and the computation time of the node $i$ as follows:
657 \begin{equation}
658   \label{eq:Scp}
659   \Scp[i] = \frac{\max_{i=1,2,\dots,N}(\Tcp[i])}{\Tcp[i]}
660 \end{equation}
661 Using the initial frequency scaling factors computed in (\ref{eq:Scp}), the
662 algorithm computes the initial frequencies for all nodes as a ratio between the
663 maximum frequency of node $i$ and the computation scaling factor $\Scp[i]$ as
664 follows:
665 \begin{equation}
666   \label{eq:Fint}
667   F_{i} = \frac{\Fmax[i]}{\Scp[i]},~{i=1,2,\dots,N}
668 \end{equation}
669 If the computed initial frequency for a node is not available in the gears of
670 that node, it is replaced by the nearest available frequency.  In
671 Figure~\ref{fig:st_freq}, the nodes are sorted by their computing power in
672 ascending order and the frequencies of the faster nodes are scaled down
673 according to the computed initial frequency scaling factors.  The resulting new
674 frequencies are highlighted in Figure~\ref{fig:st_freq}.  This set of
675 frequencies can be considered as a higher bound for the search space of the
676 optimal vector of frequencies because selecting scaling factors higher
677 than the higher bound will not improve the performance of the application and it
678 will increase its overall energy consumption.  Therefore the algorithm that
679 selects the frequency scaling factors starts the search method from these
680 initial frequencies and takes a downward search direction toward lower
681 frequencies. The algorithm iterates on all remaining frequencies, from the higher
682 bound until all nodes reach their minimum frequencies, to compute their overall
683 energy consumption and performance, and select the optimal frequency scaling
684 factors vector. At each iteration the algorithm determines the slowest node
685 according to the equation (\ref{eq:perf}) and keeps its frequency unchanged,
686 while it lowers the frequency of all other nodes by one gear.  The new overall
687 energy consumption and execution time are computed according to the new scaling
688 factors.  The optimal set of frequency scaling factors is the set that gives the
689 highest distance according to the objective function (\ref{eq:max}).
690
691 Figures~\ref{fig:r1} and \ref{fig:r2} illustrate the normalized performance and
692 consumed energy for an application running on a homogeneous platform and a
693 heterogeneous platform respectively while increasing the scaling factors. It can
694 be noticed that in a homogeneous platform the search for the optimal scaling
695 factor should start from the maximum frequency because the performance and the
696 consumed energy decrease from the beginning of the plot. On the other hand, in
697 the heterogeneous platform the performance is maintained at the beginning of the
698 plot even if the frequencies of the faster nodes decrease until the computing
699 power of scaled down nodes are lower than the slowest node. In other words,
700 until they reach the higher bound. It can also be noticed that the higher the
701 difference between the faster nodes and the slower nodes is, the bigger the
702 maximum distance between the energy curve and the performance curve is while the
703 scaling factors are varying which results in bigger energy savings. 
704 Finally, in a homogeneous platform the energy consumption is increased when the scaling factor is very high. 
705 Indeed, the dynamic energy  saved  by reducing the frequency of the processor is compensated by the significant increase of the execution time and thus the increased of the static energy. On the other hand, in a heterogeneous platform this is not the case.
706
707 \subsection{The evaluation of the proposed algorithm}
708 \label{sec.verif.algo}
709
710 The precision of the proposed algorithm mainly depends on the execution time
711 prediction model defined in (\ref{eq:perf}) and the energy model computed by
712 (\ref{eq:energy}).  The energy model is also significantly dependent on the
713 execution time model because the static energy is linearly related to the
714 execution time and the dynamic energy is related to the computation time. So,
715 all the works presented in this paper are based on the execution time model. To
716 verify this model, the predicted execution time was compared to the real
717 execution time over SimGrid/SMPI simulator,
718 v3.10~\cite{casanova+giersch+legrand+al.2014.versatile}, for all the NAS
719 parallel benchmarks NPB v3.3 \cite{NAS.Parallel.Benchmarks}, running class B on
720 8 or 9 nodes. The comparison showed that the proposed execution time model is
721 very precise, the maximum normalized difference between the predicted execution
722 time and the real execution time is equal to 0.03 for all the NAS benchmarks.
723
724 Since the proposed algorithm is not an exact method, it does not test all the
725 possible solutions (vectors of scaling factors) in the search space. To prove
726 its efficiency, it was compared on small instances to a brute force search
727 algorithm that tests all the possible solutions. The brute force algorithm was
728 applied to different NAS benchmarks classes with different number of nodes. The
729 solutions returned by the brute force algorithm and the proposed algorithm were
730 identical and the proposed algorithm was on average 10 times faster than the
731 brute force algorithm. It has a small execution time: for a heterogeneous
732 cluster composed of four different types of nodes having the characteristics
733 presented in Table~\ref{table:platform}, it takes on average \np[ms]{0.04} for 4
734 nodes and \np[ms]{0.15} on average for 144 nodes to compute the best scaling
735 factors vector.  The algorithm complexity is $O(F\cdot N)$, where $F$ is the
736 maximum number of available frequencies, and $N$ is the number of computing
737 nodes. The algorithm needs from 12 to 20 iterations to select the best vector of
738 frequency scaling factors that gives the results of the next sections.
739
740 \begin{table}[!t]
741   \caption{Heterogeneous nodes characteristics}
742   % title of Table
743   \centering
744   \begin{tabular}{|*{7}{r|}}
745     \hline
746     Node   & Simulated & Max   & Min   & Diff. & Dynamic    & Static    \\
747     type   & GFLOPS    & Freq. & Freq. & Freq. & power      & power     \\
748            &           & GHz   & GHz   & GHz   &            &           \\
749     \hline
750     1      & 40        & 2.50  & 1.20  & 0.100 & \np[W]{20} & \np[W]{4} \\
751     \hline
752     2      & 50        & 2.66  & 1.60  & 0.133 & \np[W]{25} & \np[W]{5} \\
753     \hline
754     3      & 60        & 2.90  & 1.20  & 0.100 & \np[W]{30} & \np[W]{6} \\
755     \hline
756     4      & 70        & 3.40  & 1.60  & 0.133 & \np[W]{35} & \np[W]{7} \\
757     \hline
758   \end{tabular}
759   \label{table:platform}
760 \end{table}
761
762 \section{Experimental results}
763 \label{sec.expe}
764
765 To evaluate the efficiency and the overall energy consumption reduction of
766 Algorithm~\ref{HSA}, it was applied to the NAS parallel benchmarks NPB v3.3 which 
767 is composed of synchronous message passing applications. The 
768 experiments were executed on the simulator SimGrid/SMPI which offers easy tools
769 to create a heterogeneous platform and run message passing applications over it.
770 The heterogeneous platform that was used in the experiments, had one core per
771 node because just one process was executed per node.  The heterogeneous platform
772 was composed of four types of nodes. Each type of nodes had different
773 characteristics such as the maximum CPU frequency, the number of available
774 frequencies and the computational power, see Table~\ref{table:platform}. The
775 characteristics of these different types of nodes are inspired from the
776 specifications of real Intel processors.  The heterogeneous platform had up to
777 144 nodes and had nodes from the four types in equal proportions, for example if
778 a benchmark was executed on 8 nodes, 2 nodes from each type were used. Since the
779 constructors of CPUs do not specify the dynamic and the static power of their
780 CPUs, for each type of node they were chosen proportionally to its computing
781 power (FLOPS).  In the initial heterogeneous platform, while computing with
782 highest frequency, each node consumed an amount of power proportional to its
783 computing power (which corresponds to \np[\%]{80} of its dynamic power and the
784 remaining \np[\%]{20} to the static power), the same assumption was made in
785 \cite{Our_first_paper,Rauber_Analytical.Modeling.for.Energy}.  Finally, These
786 nodes were connected via an Ethernet network with \np[Gbit/s]{1} bandwidth.
787
788
789 \subsection{The experimental results of the scaling algorithm}
790 \label{sec.res}
791
792 The proposed algorithm was applied to the seven parallel NAS benchmarks (EP, CG,
793 MG, FT, BT, LU and SP) and the benchmarks were executed with the three classes:
794 A, B and C. However, due to the lack of space in this paper, only the results of
795 the biggest class, C, are presented while being run on different number of
796 nodes, ranging from 8 to 128 or 144 nodes depending on the benchmark being
797 executed. Indeed, the benchmarks CG, MG, LU, EP and FT had to be executed on 1,
798 2, 4, 8, 16, 32, 64, or 128 nodes.  The other benchmarks such as BT and SP had
799 to be executed on 1, 4, 9, 16, 36, 64, or 144 nodes.
800
801 \begin{table}[!t]
802   
803 % \end{table}
804
805   
806 % \begin{table}[!t]
807   \caption{Running NAS benchmarks on 8 and 9 nodes }
808   % title of Table
809   \centering
810   \begin{tabular}{|*{7}{r|}}
811     \hline
812     \hspace{-2.2084pt}%
813     Program & Execution & Energy        & Energy   & Performance   & Distance \\
814     name    & time/s    & consumption/J & saving\% & degradation\% &          \\
815     \hline
816     CG      &  36.11    &  3263.49      & 31.25    & 7.12          & 24.13    \\
817     \hline
818     MG      &   8.99    &   953.39      & 33.78    & 6.41          & 27.37    \\
819     \hline
820     EP      &  40.39    &  5652.81      & 27.04    & 0.49          & 26.55    \\
821     \hline
822     LU      & 218.79    & 36149.77      & 28.23    & 0.01          & 28.22    \\
823     \hline
824     BT      & 166.89    & 23207.42      & 32.32    & 7.89          & 24.43    \\
825     \hline
826     SP      & 104.73    & 18414.62      & 24.73    & 2.78          & 21.95    \\
827     \hline
828     FT      &  51.10    &  4913.26      & 31.02    & 2.54          & 28.48    \\
829     \hline
830   \end{tabular}
831   \label{table:res_8n}
832 % \end{table}
833
834   \medskip
835 % \begin{table}[!t]
836   \caption{Running NAS benchmarks on 16 nodes }
837   % title of Table
838   \centering
839   \begin{tabular}{|*{7}{r|}}
840     \hline
841     \hspace{-2.2084pt}%
842     Program & Execution & Energy        & Energy   & Performance   & Distance \\
843     name    & time/s    & consumption/J & saving\% & degradation\% &          \\
844     \hline
845     CG      &  31.74    &  4373.90      & 26.29    & 9.57          & 16.72    \\
846     \hline
847     MG      &   5.71    &  1076.19      & 32.49    & 6.05          & 26.44    \\
848     \hline
849     EP      &  20.11    &  5638.49      & 26.85    & 0.56          & 26.29    \\
850     \hline
851     LU      & 144.13    & 42529.06      & 28.80    & 6.56          & 22.24    \\
852     \hline
853     BT      &  97.29    & 22813.86      & 34.95    & 5.80          & 29.15    \\
854     \hline
855     SP      &  66.49    & 20821.67      & 22.49    & 3.82          & 18.67    \\
856     \hline
857     FT      &  37.01    &  5505.60      & 31.59    & 6.48          & 25.11    \\
858     \hline
859   \end{tabular}
860   \label{table:res_16n}
861 % \end{table}
862
863   \medskip
864 % \begin{table}[!t]
865   \caption{Running NAS benchmarks on 32 and 36 nodes }
866   % title of Table
867   \centering
868   \begin{tabular}{|*{7}{r|}}
869     \hline
870     \hspace{-2.2084pt}%
871     Program & Execution & Energy        & Energy   & Performance   & Distance \\
872     name    & time/s    & consumption/J & saving\% & degradation\% &          \\
873     \hline
874     CG      & 32.35     &  6704.21      & 16.15    & 5.30          & 10.85    \\
875     \hline
876     MG      &  4.30     &  1355.58      & 28.93    & 8.85          & 20.08    \\
877     \hline
878     EP      &  9.96     &  5519.68      & 26.98    & 0.02          & 26.96    \\
879     \hline
880     LU      & 99.93     & 67463.43      & 23.60    & 2.45          & 21.15    \\
881     \hline
882     BT      & 48.61     & 23796.97      & 34.62    & 5.83          & 28.79    \\
883     \hline
884     SP      & 46.01     & 27007.43      & 22.72    & 3.45          & 19.27    \\
885     \hline
886     FT      & 28.06     &  7142.69      & 23.09    & 2.90          & 20.19    \\
887     \hline
888   \end{tabular}
889   \label{table:res_32n}
890 % \end{table}
891
892   \medskip
893 % \begin{table}[!t]
894   \caption{Running NAS benchmarks on 64 nodes }
895   % title of Table
896   \centering
897   \begin{tabular}{|*{7}{r|}}
898     \hline
899     \hspace{-2.2084pt}%
900     Program & Execution & Energy        & Energy   & Performance   & Distance \\
901     name    & time/s    & consumption/J & saving\% & degradation\% &          \\
902     \hline
903     CG      & 46.65     &  17521.83     &  8.13    &  1.68         &  6.45    \\
904     \hline
905     MG      &  3.27     &   1534.70     & 29.27    & 14.35         & 14.92    \\
906     \hline
907     EP      &  5.05     &   5471.11     & 27.12    &  3.11         & 24.01    \\
908     \hline
909     LU      & 73.92     & 101339.16     & 21.96    &  3.67         & 18.29    \\
910     \hline
911     BT      & 39.99     &  27166.71     & 32.02    & 12.28         & 19.74    \\
912     \hline
913     SP      & 52.00     &  49099.28     & 24.84    &  0.03         & 24.81    \\
914     \hline
915     FT      & 25.97     &  10416.82     & 20.15    &  4.87         & 15.28    \\
916     \hline
917   \end{tabular}
918   \label{table:res_64n}
919 % \end{table}
920
921   \medskip
922 % \begin{table}[!t]
923   \caption{Running NAS benchmarks on 128 and 144 nodes }
924   % title of Table
925   \centering
926   \begin{tabular}{|*{7}{r|}}
927     \hline
928     \hspace{-2.2084pt}%
929     Program & Execution & Energy        & Energy   & Performance   & Distance \\
930     name    & time/s    & consumption/J & saving\% & degradation\% &          \\
931     \hline
932     CG      & 56.92     &  41163.36     &  4.00    &  1.10         &  2.90    \\
933     \hline
934     MG      &  3.55     &   2843.33     & 18.77    & 10.38         &  8.39    \\
935     \hline
936     EP      &  2.67     &   5669.66     & 27.09    &  0.03         & 27.06    \\
937     \hline
938     LU      & 51.23     & 144471.90     & 16.67    &  2.36         & 14.31    \\
939     \hline
940     BT      & 37.96     &  44243.82     & 23.18    &  1.28         & 21.90    \\
941     \hline
942     SP      & 64.53     & 115409.71     & 26.72    &  0.05         & 26.67    \\
943     \hline
944     FT      & 25.51     &  18808.72     & 12.85    &  2.84         & 10.01    \\
945     \hline
946   \end{tabular}
947   \label{table:res_128n}
948 \end{table}
949
950 \begin{figure}[!t]
951   \centering
952   \subfloat[Energy saving (\%)]{%
953     \includegraphics[width=.33\textwidth]{fig/energy}\label{fig:energy}}%
954
955   \subfloat[Performance degradation (\%)]{%
956     \includegraphics[width=.33\textwidth]{fig/per_deg}\label{fig:per_deg}}
957   \label{fig:avg}
958   \caption{The energy and performance for all NAS benchmarks running with a different number of nodes}
959 \end{figure}
960
961 The overall energy consumption was computed for each instance according to the
962 energy consumption model (\ref{eq:energy}), with and without applying the
963 algorithm. The execution time was also measured for all these experiments. Then,
964 the energy saving and performance degradation percentages were computed for each
965 instance.  The results are presented in Tables 
966 \ref{table:res_8n}, \ref{table:res_16n}, \ref{table:res_32n},
967 \ref{table:res_64n} and \ref{table:res_128n}. All these results are the average
968 values from many experiments for energy savings and performance degradation.
969 The tables show the experimental results for running the NAS parallel benchmarks
970 on different numbers of nodes.  The experiments show that the algorithm
971 significantly reduces the energy consumption (up to \np[\%]{34}) and tries to
972 limit the performance degradation.  They also show that the energy saving
973 percentage decreases when the number of computing nodes increases.  This
974 reduction is due to the increase of the communication times compared to the
975 execution times when the benchmarks are run over a higher number of nodes.
976 Indeed, the benchmarks with the same class, C, are executed on different numbers
977 of nodes, so the computation required for each iteration is divided by the
978 number of computing nodes.  On the other hand, more communications are required
979 when increasing the number of nodes so the static energy increases linearly
980 according to the communication time and the dynamic power is less relevant in
981 the overall energy consumption.  Therefore, reducing the frequency with
982 Algorithm~\ref{HSA} is less effective in reducing the overall energy savings. It
983 can also be noticed that for the benchmarks EP and SP that contain little or no
984 communications, the energy savings are not significantly affected by the high
985 number of nodes.  No experiments were conducted using bigger classes than D,
986 because they require a lot of memory (more than \np[GB]{64}) when being executed
987 by the simulator on one machine.  The maximum distance between the normalized
988 energy curve and the normalized performance for each instance is also shown in
989 the result tables. It decrease in the same way as the energy saving percentage.
990 The tables also show that the performance degradation percentage is not
991 significantly increased when the number of computing nodes is increased because
992 the computation times are small when compared to the communication times.
993
994 Figures~\ref{fig:energy} and \ref{fig:per_deg} present the energy saving and
995 performance degradation respectively for all the benchmarks according to the
996 number of used nodes. As shown in the first plot, the energy saving percentages
997 of the benchmarks MG, LU, BT and FT decrease linearly when the number of nodes
998 increase. While for the EP and SP benchmarks, the energy saving percentage is
999 not affected by the increase of the number of computing nodes, because in these
1000 benchmarks there are little or no communications. Finally, the energy saving of
1001 the CG benchmark significantly decreases when the number of nodes increase
1002 because this benchmark has more communications than the others. The second plot
1003 shows that the performance degradation percentages of most of the benchmarks
1004 decrease when they run on a big number of nodes because they spend more time
1005 communicating than computing, thus, scaling down the frequencies of some nodes
1006 has less effect on the performance.
1007
1008 \subsection{The results for different power consumption scenarios}
1009 \label{sec.compare}
1010
1011 The results of the previous section were obtained while using processors that
1012 consume during computation an overall power which is \np[\%]{80} composed of
1013 dynamic power and of \np[\%]{20} of static power. In this section, these ratios
1014 are changed and two new power scenarios are considered in order to evaluate how
1015 the proposed algorithm adapts itself according to the static and dynamic power
1016 values.  The two new power scenarios are the following:
1017
1018 \begin{itemize}
1019 \item \np[\%]{70} of dynamic power and \np[\%]{30} of static power
1020 \item \np[\%]{90} of dynamic power and \np[\%]{10} of static power
1021 \end{itemize}
1022
1023 The NAS parallel benchmarks were executed again over processors that follow the
1024 new power scenarios.  The class C of each benchmark was run over 8 or 9 nodes
1025 and the results are presented in Tables~\ref{table:res_s1} and
1026 \ref{table:res_s2}. These tables show that the energy saving percentage of the
1027 \np[\%]{70}-\np[\%]{30} scenario is smaller for all benchmarks compared to the
1028 energy saving of the \np[\%]{90}-\np[\%]{10} scenario.  Indeed, in the latter
1029 more dynamic power is consumed when nodes are running on their maximum
1030 frequencies, thus, scaling down the frequency of the nodes results in higher
1031 energy savings than in the \np[\%]{70}-\np[\%]{30} scenario. On the other hand,
1032 the performance degradation percentage is smaller in the \np[\%]{70}-\np[\%]{30}
1033 scenario compared to the \np[\%]{90}-\np[\%]{10} scenario. This is due to the
1034 higher static power percentage in the first scenario which makes it more
1035 relevant in the overall consumed energy.  Indeed, the static energy is related
1036 to the execution time and if the performance is degraded the amount of consumed
1037 static energy directly increases.  Therefore, the proposed algorithm does not
1038 really significantly scale down much the frequencies of the nodes in order to
1039 limit the increase of the execution time and thus limiting the effect of the
1040 consumed static energy.
1041
1042 Both new power scenarios are compared to the old one in
1043 Figure~\ref{fig:sen_comp}. It shows the average of the performance degradation,
1044 the energy saving and the distances for all NAS benchmarks of class C running on
1045 8 or 9 nodes.  The comparison shows that the energy saving ratio is proportional
1046 to the dynamic power ratio: it is increased when applying the
1047 \np[\%]{90}-\np[\%]{10} scenario because at maximum frequency the dynamic energy
1048 is the most relevant in the overall consumed energy and can be reduced by
1049 lowering the frequency of some processors. On the other hand, the energy saving
1050 decreases when the \np[\%]{70}-\np[\%]{30} scenario is used because the dynamic
1051 energy is less relevant in the overall consumed energy and lowering the
1052 frequency does not return big energy savings.  Moreover, the average of the
1053 performance degradation is decreased when using a higher ratio for static power
1054 (e.g.  \np[\%]{70}-\np[\%]{30} scenario and \np[\%]{80}-\np[\%]{20}
1055 scenario). Since the proposed algorithm optimizes the energy consumption when
1056 using a higher ratio for dynamic power the algorithm selects bigger frequency
1057 scaling factors that result in more energy saving but less performance, for
1058 example see Figure~\ref{fig:scales_comp}. The opposite happens when using a
1059 higher ratio for static power, the algorithm proportionally selects smaller
1060 scaling values which result in less energy saving but also less performance
1061 degradation.
1062
1063 \begin{table}[!t]
1064   \caption{The results of the \np[\%]{70}-\np[\%]{30} power scenario}
1065   % title of Table
1066   \centering
1067   \begin{tabular}{|*{6}{r|}}
1068     \hline
1069     Program & Energy        & Energy   & Performance   & Distance \\
1070     name    & consumption/J & saving\% & degradation\% &          \\
1071     \hline
1072     CG      &  4144.21      & 22.42    & 7.72          & 14.70    \\
1073     \hline
1074     MG      &  1133.23      & 24.50    & 5.34          & 19.16    \\
1075    \hline
1076     EP      &  6170.30      & 16.19    & 0.02          & 16.17    \\
1077    \hline
1078     LU      & 39477.28      & 20.43    & 0.07          & 20.36    \\
1079     \hline
1080     BT      & 26169.55      & 25.34    & 6.62          & 18.71    \\
1081    \hline
1082     SP      & 19620.09      & 19.32    & 3.66          & 15.66    \\
1083    \hline
1084     FT      &  6094.07      & 23.17    & 0.36          & 22.81    \\
1085     \hline
1086   \end{tabular}
1087   \label{table:res_s1}
1088 \end{table}
1089
1090 \begin{table}[!t]
1091   \caption{The results of the \np[\%]{90}-\np[\%]{10} power scenario}
1092   % title of Table
1093   \centering
1094   \begin{tabular}{|*{6}{r|}}
1095     \hline
1096     Program & Energy          & Energy      & Performance   & Distance \\
1097     name    & consumption/J   & saving\%    & degradation\% &          \\
1098     \hline
1099     CG      &  2812.38        & 36.36       &  6.80         & 29.56    \\
1100     \hline
1101     MG      &   825.43        & 38.35       &  6.41         & 31.94    \\
1102     \hline
1103     EP      &  5281.62        & 35.02       &  2.68         & 32.34    \\
1104     \hline
1105     LU      & 31611.28        & 39.15       &  3.51         & 35.64    \\
1106     \hline
1107     BT      & 21296.46        & 36.70       &  6.60         & 30.10    \\
1108     \hline
1109     SP      & 15183.42        & 35.19       & 11.76         & 23.43    \\
1110     \hline
1111     FT      &  3856.54        & 40.80       &  5.67         & 35.13    \\
1112     \hline
1113   \end{tabular}
1114   \label{table:res_s2}
1115 \end{table}
1116
1117 \begin{table}[!t]
1118   \caption{Comparing the proposed algorithm}
1119   \centering
1120   \begin{tabular}{|*{7}{r|}}
1121     \hline
1122     Program & \multicolumn{2}{c|}{Energy saving \%}
1123             & \multicolumn{2}{c|}{Perf.  degradation \%}
1124             & \multicolumn{2}{c|}{Distance} \\
1125     \cline{2-7}
1126     name    & EDP   & MaxDist & EDP  & MaxDist & EDP   & MaxDist \\
1127     \hline
1128     CG      & 27.58 & 31.25   & 5.82 & 7.12    & 21.76 & 24.13   \\
1129     \hline
1130     MG      & 29.49 & 33.78   & 3.74 & 6.41    & 25.75 & 27.37   \\
1131     \hline
1132     LU      & 19.55 & 28.33   & 0.00 & 0.01    & 19.55 & 28.22   \\
1133     \hline
1134     EP      & 28.40 & 27.04   & 4.29 & 0.49    & 24.11 & 26.55   \\
1135     \hline
1136     BT      & 27.68 & 32.32   & 6.45 & 7.87    & 21.23 & 24.43   \\
1137     \hline
1138     SP      & 20.52 & 24.73   & 5.21 & 2.78    & 15.31 & 21.95   \\
1139     \hline
1140     FT      & 27.03 & 31.02   & 2.75 & 2.54    & 24.28 & 28.48   \\
1141     \hline
1142   \end{tabular}
1143   \label{table:compare_EDP}
1144 \end{table}
1145
1146 \begin{figure}[!t]
1147   \centering
1148   \subfloat[Comparison  between the results on 8 nodes]{%
1149     \includegraphics[width=.33\textwidth]{fig/sen_comp}\label{fig:sen_comp}}%
1150
1151   \subfloat[Comparison the selected frequency scaling factors of MG benchmark class C running on 8 nodes]{%
1152     \includegraphics[width=.33\textwidth]{fig/three_scenarios}\label{fig:scales_comp}}
1153   \label{fig:comp}
1154   \caption{The comparison of the three power scenarios}
1155 \end{figure}
1156
1157 \begin{figure}[!t]
1158   \centering
1159    \includegraphics[scale=0.5]{fig/compare_EDP.pdf}
1160   \caption{Trade-off comparison for NAS benchmarks class C}
1161   \label{fig:compare_EDP}
1162 \end{figure}
1163
1164
1165 \subsection{The comparison of the proposed scaling algorithm }
1166 \label{sec.compare_EDP}
1167
1168 In this section, the scaling factors selection algorithm, called MaxDist, is
1169 compared to Spiliopoulos et al. algorithm
1170 \cite{Spiliopoulos_Green.governors.Adaptive.DVFS}, called EDP.  They developed a
1171 green governor that regularly applies an online frequency selecting algorithm to
1172 reduce the energy consumed by a multicore architecture without degrading much
1173 its performance. The algorithm selects the frequencies that minimize the energy
1174 and delay products, $\mathit{EDP}=\mathit{energy}\times \mathit{delay}$ using
1175 the predicted overall energy consumption and execution time delay for each
1176 frequency.  To fairly compare both algorithms, the same energy and execution
1177 time models, equations (\ref{eq:energy}) and (\ref{eq:fnew}), were used for both
1178 algorithms to predict the energy consumption and the execution times. Also
1179 Spiliopoulos et al. algorithm was adapted to start the search from the initial
1180 frequencies computed using the equation (\ref{eq:Fint}). The resulting algorithm
1181 is an exhaustive search algorithm that minimizes the EDP and has the initial
1182 frequencies values as an upper bound.
1183
1184 Both algorithms were applied to the parallel NAS benchmarks to compare their
1185 efficiency. Table~\ref{table:compare_EDP} presents the results of comparing the
1186 execution times and the energy consumption for both versions of the NAS
1187 benchmarks while running the class C of each benchmark over 8 or 9 heterogeneous
1188 nodes. The results show that our algorithm provides better energy savings than
1189 Spiliopoulos et al. algorithm, on average it results in \np[\%]{29.76} energy
1190 saving while their algorithm returns just \np[\%]{25.75}. The average of
1191 performance degradation percentage is approximately the same for both
1192 algorithms, about \np[\%]{4}.
1193
1194 For all benchmarks,  our algorithm outperforms Spiliopoulos et  al. algorithm in
1195 terms of  energy and  performance trade-off, see  Figure~\ref{fig:compare_EDP},
1196 because it maximizes the distance  between the energy saving and the performance
1197 degradation values while giving the same weight for both metrics.
1198
1199 \section{Conclusion}
1200 \label{sec.concl}
1201
1202 In this paper, a new online frequency selecting algorithm has been presented. It
1203 selects the best possible vector of frequency scaling factors that gives the
1204 maximum distance (optimal trade-off) between the predicted energy and the
1205 predicted performance curves for a heterogeneous platform. This algorithm uses a
1206 new energy model for measuring and predicting the energy of distributed
1207 iterative applications running over heterogeneous platforms. To evaluate the
1208 proposed method, it was applied on the NAS parallel benchmarks and executed over
1209 a heterogeneous platform simulated by SimGrid. The results of the experiments
1210 showed that the algorithm reduces up to \np[\%]{34} the energy consumption of a
1211 message passing iterative method while limiting the degradation of the
1212 performance. The algorithm also selects different scaling factors according to
1213 the percentage of the computing and communication times, and according to the
1214 values of the static and dynamic powers of the CPUs.  Finally, the algorithm was
1215 compared to Spiliopoulos et al.  algorithm and the results showed that it
1216 outperforms their algorithm in terms of energy-time trade-off.
1217
1218 In the near future, this method  will be applied to real heterogeneous platforms
1219 to evaluate its  performance in a real study case. It  would also be interesting
1220 to evaluate its scalability over large scale heterogeneous platforms and measure
1221 the energy  consumption reduction it can  produce.  Afterward, we  would like to
1222 develop a similar method that  is adapted to asynchronous iterative applications
1223 where  each task  does not  wait for  other tasks  to finish  their  works.  The
1224 development of such a method might require a new energy model because the number
1225 of iterations is  not known in advance and depends on  the global convergence of
1226 the iterative system.
1227
1228 \section*{Acknowledgment}
1229
1230 This work  has been  partially supported by  the Labex ACTION  project (contract
1231 ``ANR-11-LABX-01-01'').  Computations  have been performed  on the supercomputer
1232 facilities  of the  Mésocentre de  calcul de  Franche-Comté. As  a  PhD student,
1233 Mr. Ahmed  Fanfakh, would  like to  thank the University  of Babylon  (Iraq) for
1234 supporting his work.
1235
1236 % trigger a \newpage just before the given reference
1237 % number - used to balance the columns on the last page
1238 % adjust value as needed - may need to be readjusted if
1239 % the document is modified later
1240 %\IEEEtriggeratref{15}
1241
1242 \bibliographystyle{IEEEtran}
1243 \bibliography{IEEEabrv,my_reference}
1244 \end{document}
1245
1246 %%% Local Variables:
1247 %%% mode: latex
1248 %%% TeX-master: t
1249 %%% fill-column: 80
1250 %%% ispell-local-dictionary: "american"
1251 %%% End:
1252
1253 % LocalWords:  Fanfakh Charr FIXME Tianhe DVFS HPC NAS NPB SMPI Rauber's Rauber
1254 % LocalWords:  CMOS EPSA Franche Comté Tflop Rünger IUT Maréchal Juin cedex GPU
1255 % LocalWords:  de badri muslim MPI SimGrid GFlops Xeon EP BT GPUs CPUs AMD
1256 %  LocalWords:  Spiliopoulos scalability