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

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