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

Private GIT Repository
e7525c15231fa124332292a6c386c8d871ea3c53
[mpi-energy2.git] / mpi-energy2-extension / review / review.tex
1 \documentclass[12pt,a4paper]{journal}
2 \usepackage[utf8]{inputenc}
3 \usepackage{amsmath}
4 \usepackage{amsfonts}
5 \usepackage{amssymb}
6 \usepackage{graphicx}
7 \usepackage{color}
8 %\title{Reviewers' comments}
9
10 \newcommand{\AG}[2][inline]{%
11   \todo[color=green!50,#1]{\sffamily\textbf{AG:} #2}\xspace}
12 \newcommand{\JC}[2][inline]{%
13   \todo[color=red!10,#1]{\sffamily\textbf{JC:} #2}\xspace}
14
15 \newcommand{\Xsub}[2]{{\ensuremath{#1_\mathit{#2}}}}
16
17 %% used to put some subscripts lower, and make them more legible
18 \newcommand{\fxheight}[1]{\ifx#1\relax\relax\else\rule{0pt}{1.52ex}#1\fi}
19
20 \newcommand{\CL}{\Xsub{C}{L}}
21 \newcommand{\Dist}{\mathit{Dist}}
22 \newcommand{\EdNew}{\Xsub{E}{dNew}}
23 \newcommand{\Eind}{\Xsub{E}{ind}}
24 \newcommand{\Enorm}{\Xsub{E}{Norm}}
25 \newcommand{\Eoriginal}{\Xsub{E}{Original}}
26 \newcommand{\Ereduced}{\Xsub{E}{Reduced}}
27 \newcommand{\Es}{\Xsub{E}{S}}
28 \newcommand{\Fdiff}[1][]{\Xsub{F}{diff}_{\!#1}}
29 \newcommand{\Fmax}[1][]{\Xsub{F}{max}_{\fxheight{#1}}}
30 \newcommand{\Fnew}{\Xsub{F}{new}}
31 \newcommand{\Ileak}{\Xsub{I}{leak}}
32 \newcommand{\Kdesign}{\Xsub{K}{design}}
33 \newcommand{\MaxDist}{\mathit{Max}\Dist}
34 \newcommand{\MinTcm}{\mathit{Min}\Tcm}
35 \newcommand{\Ntrans}{\Xsub{N}{trans}}
36 \newcommand{\Pd}[1][]{\Xsub{P}{d}_{\fxheight{#1}}}
37 \newcommand{\PdNew}{\Xsub{P}{dNew}}
38 \newcommand{\PdOld}{\Xsub{P}{dOld}}
39 \newcommand{\Pnorm}{\Xsub{P}{Norm}}
40 \newcommand{\Ps}[1][]{\Xsub{P}{s}_{\fxheight{#1}}}
41 \newcommand{\Scp}[1][]{\Xsub{S}{cp}_{#1}}
42 \newcommand{\Sopt}[1][]{\Xsub{S}{opt}_{#1}}
43 \newcommand{\Tcm}[1][]{\Xsub{T}{cm}_{\fxheight{#1}}}
44 \newcommand{\Tcp}[1][]{\Xsub{T}{cp}_{#1}}
45 \newcommand{\Pmax}[1][]{\Xsub{P}{max}_{\fxheight{#1}}}
46 \newcommand{\Pidle}[1][]{\Xsub{P}{idle}_{\fxheight{#1}}}
47 \newcommand{\TcpOld}[1][]{\Xsub{T}{cpOld}_{#1}}
48 \newcommand{\Tnew}{\Xsub{T}{New}}
49 \newcommand{\Told}{\Xsub{T}{Old}}
50
51
52
53 \begin{document}
54
55 \title{Answers to the questions of the reviewers}
56 \maketitle
57 \section{Questions of the first reviewer} 
58
59 \begin{enumerate}
60
61
62
63 \item In Sec. 5, I found intriguing the fact of executing Algorithm 1 only
64 after the first iteration. I agree with you that your model finds the
65 best trade-off given some data, but what about the variability? We
66 know computer systems today always show some variability. You are
67 measuring the computation time and energy consumption for one
68 iteration only. Let's suppose something went bad in this first
69 iteration. The scaling factors will not be the best tradeoff because
70 variability has been ignored. What would be the solution for that?
71 Consider variability in the model. 
72
73 \textbf{Answer:} In this paper we have considered that the application executes regular iterations over stable computers computing only this application. Therefore, we have assumed that the execution times of all the iterations of the application executed on the same computing node should be almost the same. For this reason we did not take into consideration the variability of the computer system. Moreover, applying the frequency scaling algorithm after many iterations would reduce its impact on the energy consumption especially for applications executing a relatively low number of iterations. 
74
75 However, the variability of the computing system can be taken into consideration in a future work. For example, the proposed algorithm can be executed twice: after the first iteration the frequencies are scaled down according to the execution times measured in the first iteration, then after a fixed number of iterations, the frequencies are adjusted according to the execution times measured during the fixed number of iterations. If the  computing power of the system is constantly changing, it would be interesting to implement a mechanism that detects this change and adjusts the frequencies according to the variability of the system. 
76
77  Taking account of the variability of the system has been added as a perspective at the end of the paper.
78
79
80 \item Another point is that you mention
81 in the abstract and introduction that your solution has low overhead,
82 but it is a centralized solution. Probably it won't scale when we
83 reach hundreds or thousands of computer nodes: take one of that large
84 machines for example. In this paper experiments, only 16 and 32 nodes
85 where considered.
86
87 \textbf{Answer:}
88 We agree with the reviewer that the algorithm is centralized and might be a bottleneck if it was applied to an application running on many thousands of nodes. However, up to 144 nodes in a heterogeneous cluster, the overhead of the algorithm was very small, 0.15 ms, as presented in the simulation results of [6]. We did not execute experiments with more than 32 nodes on Grid'5000 because it does not have many nodes that allow DVFS operations and have energy measurement tools. 
89
90 On the other hand, the scalability of the proposed algorithm can be improved if we use asynchronous computations or if the algorithm was distributed in a hierarchical manner where a leader is chosen for each cluster or a group of nodes  to compute their scaled frequencies. Improving the scalability of the algorithm is beyond the scope of this paper.
91
92
93
94 \item In Fig 6, you draw lines between the points. Lines here mean nothing
95 since you are changing the benchmark. I would replot using for
96 instance a non-stacked bar plot with four colors (one site/16, one 
97 site/32, two sites/16, two sites/32). I believe it would be much
98 easier to compare and avoid the problem of lines.
99
100  \textbf{Answer:} We agree with the reviewer. The curves in Figures 6 and 8 in the paper were replaced by histograms.
101  
102
103
104
105 \item About the discussion of results shown in Fig 7, one consideration
106 draws my attention: "(...) the increase in the number of computing
107 nodes can increase the communication times and thus produces less
108 energy saving depending on the benchmarks being executed.". I agree
109 with you that for very large applications, synchronous collective
110 operations are very costly (take a very simple MPI-Allgather for
111 instance). You say that on scale this would produce less energy
112 savings, but your arguments for providing a solution for this was
113 based that today's supercomputers are achieving massive scale.
114
115 \textbf{Answer:} In the Figure 7, the energy consumption of the benchmarks solving the class D and running on many scenarios are presented. The number of used nodes varies between 16 and 32 in the scenarios while the size of the problem is not modified. Therefore, the computations to communications times ratio is lower when 32 nodes are used instead of 16. When this ratio is small, it means there are not enough computations when compared to the communications times and the impact of scaling down the frequency of the CPU on its energy consumption is reduced. To solve this problem, the problem 
116 should be solved on a number of nodes adequate to its size. For example, for the NAS benchmarks, the class E should have been solved on 32 nodes to have a good computations to communications times ratio.  
117
118
119 \item In Sec 6.3, why did you choose to keep 32 processes for the evaluation
120 with multi-core clusters? How did you configure MPI for the results
121
122 \textcolor{blue}{Answer:  We keep choosing 32 nodes in both scenarios 
123 to compare them while one core per node scenario has distributed communications (one network link for each node) and multi-core scenario uses shared network link communications and thus comparing their impact on the results. 
124 We configure MPI on one core per node scenario by choosing one core per  nodes (e.g in machine file we did: node1, node2 ,node3, node4). While in multi-core scenario we choose one machine with four cores (e.g. node1 slots=4).}
125  
126
127 \item shown in Fig 8a? Some MPI implementations have an option to use shared
128 memory when processes share the same processor. I agree with you in
129 the explanation of the network card utilization, but this
130 shared-memory optimization is possible (sometimes automatically
131 detected by MPI if you pin processes to cores).
132
133 \textcolor{blue}{Answer: We didn't  manually pin processes to cores and since the communication times  
134 increased. We guess that the shared memory wasn't used.}
135
136 \item In P33, Sec 6.5, you mention that the proposed algorithm outperforms
137 EDP because the former considers both metrics (time, energy) and the
138 same time. EDP does also, but using a single metric which you have
139 defined: energy x execution time. I think this is only a matter of
140 phrasing.
141
142 \textcolor{blue}{Answer: we use the delay in execution time not the execution time. Then, the equation that we used is EDP= energy x (Tnew-Told). The experiments shows that our objective function 
143 is better than the EDP objective.}
144
145
146 \item Other complementary points to consider:
147
148 + P2, L51: there are three dots that looks like an error.
149
150 + P4, L36: also unusual three dots at the end of paragraph.
151
152 + P14 also has three dots in phrase endings. I consider this bad writing style.
153
154 + Fig 2b is missing the X scale ticks. You could show some examples of vectors.
155
156 + P23: "static power is assumed to be equal to 20\% of dynamic". Provide citation.
157
158 + Fig 6 is referenced in P23, but appears only in P25. Hard to read.
159
160 + Same for Fig 7.
161
162 \item \textcolor{blue}{ Answer: We have considered these points in the paper.}
163
164 \item From the design of experiments, did you consider using replications?
165 There is no variability metric in your results. Have you run multiple
166 times and got the average (execution time and energy consumption)? I
167 feel that such variability needs to be accounted for, otherwise it is
168 very hard to affirm anything about measurements.
169
170  \textcolor{blue}{Answer: Each experiment has been executed many times and the results presented in the 
171  figures are the average values of many executions.}
172
173
174 \item In summary, I think this is a very interesting work but the experimental evaluation lacks variability measurements, consider larger experiments (1K nodes for instance) to see how everything scales,  and there is no overhead measurements although authors stress that in abstract/introduction.
175
176 \textcolor{blue}{Answer: We will expand the experimental over a large number of nodes in the future work while increasing the  problem size and considering the variability issues. We have discussed the algorithm overhead and its complexity in section 6.5.}
177 \end{enumerate}
178
179
180 \section{Questions of the second reviewer} 
181 This paper presents detailed performance and energy model for iterative message passing applications. Further a method is proposed to select the frequencies of heterogeneous cpus online. The selection method itself is not difficult. But I like the systematic modeling for energy consumption and performance. This paper is well written in general. The technical contents are presented in a logical way overall. The experiments are conducted in real platform, which shows the practicality of this work and also makes the work have more impact on the field. However, I have the following comments and concerns for this paper. The authors should clarify them in the revised version. 
182
183
184 -move the contributions from related work to introduction
185
186 \begin{enumerate}
187
188
189 \item why emphasize it is a grid platform? the presentation of related work follows the logic of heterogeneous CPUs. Grid is only a type of platform with heterogeneous CPUs
190
191 \textcolor{blue}{Answer: The proposed algorithm was adapted to the grid platform which is composed 
192 of homogeneous clusters and interconnected by a wide area network which is slower than the local 
193 network in each cluster. The algorithm can also work on other heterogeneous platforms.} 
194
195
196 \item Define what iterative message passing applications are and give exemplar applications of them targeted by this method. 
197
198 \textcolor{blue}{Answer: The message passing applications with iterations compute
199 the same block of operations several times, starting from the initial solution until reaching
200 the acceptable approximation of the exact solution (we have added this sentence to the paper page 21). 
201 There are many example for these applications 
202 such as JACOBI, GAUSS-SEIDE, Successive over-relaxation and  conjugate gradient (CG) method and etc.
203 Similarly, an offline method uses DVFS and applied to these applications is in \cite{1} } 
204
205
206 \item Figure 1 is not clearly explained. Where is the slack time in figure 1 and why slack time =0 for task 1?
207
208 \textcolor{blue}{Answer: We agree with the reviewer, this figure was re-plotted to show the slack time. 
209  In the figure, we assumed that task 1 is the slower task. So, there are no slack time (waiting time)
210  in the slower task because it is not wait for the others while other tasks wait for it.}
211
212 \item define the parameters in eq. 1.
213
214 \textcolor{blue}{Answer: We have defined Fmax and Fnew in the text.}
215
216 \item eq. 2: are you assuming each cluster has the same number of nodes?
217
218
219
220
221 \textcolor{blue}{Answer: No, we assume each cluster has different number of node, so in the equation we
222 have replaced $M_i$ instead of $M$ and the same for $F$ replaced with $F_j$ in the all equations of the paper.}
223
224 \item Eq.2 implicitly assumes that there is no overlapping between computation and communication. Is it reasonable?
225
226 \textcolor{blue}{Answer: The communications between the computing nodes are synchronized, where each node 
227 need to wait for the others to finished their jobs before computing the next iteration. So, there is no
228 overlapping between computations and communications for a node. The overlapping happens when the communications are asynchronous or the computations are not depend on the data sent by the neighbouring nodes. }
229
230 \item eq. 2 is not clear: 
231
232 -how to define and determine the slowest cluster h? the one before scaling or after scaling? 
233
234 \textcolor{blue}{Answer: The slower task is the task which gives maximum execution time before scaling the frequency of the node. We have added this sentence to the paper (page 8).}
235  
236
237 - what is the communication time without slack time
238
239 \textcolor{blue}{Answer: There is no synchronous communications with zero slack times, but if a node send a message to another node which is already waiting for that message. The latter will acknowledge the reception of the message from the sender without any delay. On the other hand, if the receiving  node is still computing the sender has to wait for it to finish its computation to acknowledge the reception of the message. This time is called the slack time. }
240
241
242 - in equation, min operation is used to get the communication time, but in text, it says to use the slowest communication time, which should use the max operation then.
243
244 \textcolor{blue}{Answer: We agree with the reviewer and the sentence  "slower communication time" changed to "communication time of the slower node" in the paper.}
245
246 \item discuss the difference between eq. 2 and the prediction model in references [5] and [6]
247
248 \textcolor{blue}{Answer: The prediction models  in [5] and [6] are for homogeneous and heterogeneous clusters respectively, while eq. 2 is for a grid. where the homogeneous cluster predication model was used one scaling factor denoted as $S$, because all the nodes in the cluster have the same computing powers. Whereas, in heterogeneous cluster prediction model all the nodes have different scales and the scaling factors have denoted as one dimensional vector $(S_1, S_2, \dots, S_N)$. The execution time prediction model for a grid  Equation (2) defines a two dimensional array of scales  
249 $(S_{11}, S_{12},\dots, S_{NM_i})$. We have added this to the paper (page 8).}
250
251 \item Eq. 10: Can the authors comment on the energy consumed by communications?
252
253 \textcolor{blue}{Answer: The CPU during  communications consumed only the static power power. While
254 in computations the CPU consumes both the dynamic and static communication, refer to \cite{3}. We have added this sentience to the paper, page 11.}
255
256 \item This work assume homogeneous cpu in one cluster. Line 55 says: even if the distributed message
257 passing iterative application is load balanced, the computation time of each cpu j in cluster i may be different  Why?
258
259 \textcolor{blue}{Answer: The computation times may be slightly different due to the delay caused
260 by the scheduler of the operating system. We have added this in the paper.}
261
262 \item Comment why the applications in NAS parallel benchmark are iterative application? These applications are normally run in one cluster. Describe in more detail how they are run across multiple clusters. 
263
264 \textcolor{blue}{Answer: The applications in NAS parallel benchmark are  application with iterations  because they iterate the same block of instructions (communications and computations) many times. All the benchmarks are MPI programs that allowed to be executed on any distributed memory platform such as clusters and grids with no required modifications. Since, we have deployed the same operating system on all the nodes, we just compile the source on one cluster and then copied the executable program on all the clusters. }
265
266 \item broken sentence in line 28 on page 12
267
268 \textcolor{blue}{Answer: The word "were" replaced with "where".}
269
270 \item Why $T_{old}$ is computed using eq. 12, which applies MAX over computation time and communication time, while in  $T_{new}$, max and min operations are applied over computation and communication separately?
271
272 \textcolor{blue}{Answer:  We  agree with the reviewer, $T_{old}$ is the maximum execution time of the application before scaling the frequency and it is computed as in $T_{new}$ equation without scaling factors. So, we have changed the $T_{old}$ in the paper as as follows:
273 \begin{equation}
274   \label{eq:told}
275    T_{old} = \mathop{\max_{i=1,2,\dots,N}}_{j=1,2,\dots,M_i} (\Tcp[ij]) + 
276    \mathop{\min_{i=1,2,\dots,N}} (\Tcm[hj] )           
277 \end{equation}
278 }
279
280 \item Line 55 on page 16 is to define the slack time, which should be introduced at the beginning of the paper, such as in figure 1.
281
282 \textcolor{blue}{Answer: We have changed it in the paper and added to page 6.}
283
284
285 \item Authors comment whether (and how) the proposed methods can be applied/extended to other programming models and/or platform, such as mapreduce, heterogeneous cluster with CPU+GPU.
286 Revision 
287
288 \textcolor{blue}{Answer: The proposed method can only be applied to parallel programming with iteration  
289 and with or without message passing. Indeed, the proposed method can be applied to the parallel application  with mapreduce if it is a regular application with iterations. Therefore,  the time of each map and reduce operations (communications) and the computation times in the program must be computed at the first iterations to predict the energy consumption and the execution time. After, the proposed algorithm can be used as it to select the best frequencies. 
290 The proposed method can be applied to a heterogeneous platform composed from GPUs and CPUs, since modern GPUs like CPUs allow the use of DVFS operation.}
291 \end{enumerate}
292
293 \section{Questions of the third reviewer}
294 In this paper, a new online frequency selecting algorithm for grids, composed of heterogeneous clusters, is presented. It selects the frequencies and tries to give the best trade-off between
295 energy saving and performance degradation, for each node computing the message passing iterative application. The algorithm has a small overhead and works without training or profiling. It uses a new energy model for message
296 passing iterative applications running on a grid. The proposed algorithm is evaluated on a real grid, the Grid'5000 platform, while running the NAS parallel benchmarks. The experiments on 16 nodes, distributed on three clusters, show
297 that it reduces on average the energy consumption by 30\% while the performance is on average only degraded by 3.2\%. Finally, the algorithm is compared to an existing method. The comparison results show that it outperforms the
298 latter in terms of energy consumption reduction and performance.
299
300 this paper is quite interesting and solid. But before acceptance, I suggest to have the following major revisions:
301 \begin{enumerate}
302
303 \item suggest the authors to use much larger size of nodes, instead of on 16 nodes, distributed on three clusters, to see the scalability of the energy saving
304
305 \textcolor{blue}{Answer: We have made the experiments not only on 16  nodes, but we have also made them  over 32 nodes distributed over three clusters and in the near future we will apply the proposed method over a larger number of nodes.}
306
307 \item  the energy saving is actually calculated by the quantitative formula instead of the real measurements.  Can you have any  discussions on the real measurements?
308
309 \textcolor{blue}{Answer: The scope of this paper is not mainly focuses on the energy measurements, but it focuses on modelling and optimizing the energy and performance of grid systems. The proposed energy model depends on the dynamic and static power values for each CPU. We have used a real power measurement tools allowed in Grid'5000 sites to measure the dynamic power consumption. Moreover, the real measurements are difficult  for a grid platform when the nodes are geographically distributed. As a future work, it is interesting  to compare the accuracy of the proposed energy model with a real instruments  to measure the energy consumption for local clusters such as the measurement tools presented in \cite{2}.}
310
311 \item the overhead is not measured, can you present something on this as well to demonstrate what the authors claimed "has a small overhead and works without training or profiling"?
312
313 \textcolor{blue}{Answer: In the comparison section 6.5, we have presented the execution time of the algorithm when it is executed over 32 nodes distributed over three sites located at two different sites, it takes on average 0.01 $ms$. The algorithm works online without training which means it only uses the measured communication and computation times during the runtime and do not require any profiling or training executed before runtime.}
314 \end{enumerate}
315 \bibliographystyle{plain}
316 \bibliography{ref.bib}
317
318
319 \end{document}
320