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

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