]> AND Private Git Repository - rce2015.git/blob - paper.tex
Logo AND Algorithmique Numérique Distribuée

Private GIT Repository
a2e23a24ae4510982b193106b880884da634d8dc
[rce2015.git] / paper.tex
1 \documentclass[times]{cpeauth}
2
3 \usepackage{moreverb}
4
5 %\usepackage[dvips,colorlinks,bookmarksopen,bookmarksnumbered,citecolor=red,urlcolor=red]{hyperref}
6
7 %\newcommand\BibTeX{{\rmfamily B\kern-.05em \textsc{i\kern-.025em b}\kern-.08em
8 %T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
9
10 \def\volumeyear{2015}
11
12 \usepackage{graphicx}
13 \usepackage{wrapfig}
14 \usepackage{grffile}
15
16 \usepackage[T1]{fontenc}
17 \usepackage[utf8]{inputenc}
18 \usepackage{amsfonts,amssymb}
19 \usepackage{amsmath}
20 \usepackage{algorithm}
21 \usepackage{algpseudocode}
22 %\usepackage{amsthm}
23 \usepackage{graphicx}
24 % Extension pour les liens intra-documents (tagged PDF)
25 % et l'affichage correct des URL (commande \url{http://example.com})
26 %\usepackage{hyperref}
27 \usepackage{multirow}
28
29
30 \usepackage{url}
31 \DeclareUrlCommand\email{\urlstyle{same}}
32
33 \usepackage[autolanguage,np]{numprint}
34 \AtBeginDocument{%
35   \renewcommand*\npunitcommand[1]{\text{#1}}
36   \npthousandthpartsep{}}
37
38 \usepackage{xspace}
39 \usepackage[textsize=footnotesize]{todonotes}
40
41 \newcommand{\AG}[2][inline]{%
42   \todo[color=green!50,#1]{\sffamily\textbf{AG:} #2}\xspace}
43 \newcommand{\RC}[2][inline]{%
44   \todo[color=red!10,#1]{\sffamily\textbf{RC:} #2}\xspace}
45 \newcommand{\LZK}[2][inline]{%
46   \todo[color=blue!10,#1]{\sffamily\textbf{LZK:} #2}\xspace}
47 \newcommand{\RCE}[2][inline]{%
48   \todo[color=yellow!10,#1]{\sffamily\textbf{RCE:} #2}\xspace}
49 \newcommand{\DL}[2][inline]{%
50     \todo[color=pink!10,#1]{\sffamily\textbf{DL:} #2}\xspace}
51
52 \algnewcommand\algorithmicinput{\textbf{Input:}}
53 \algnewcommand\Input{\item[\algorithmicinput]}
54
55 \algnewcommand\algorithmicoutput{\textbf{Output:}}
56 \algnewcommand\Output{\item[\algorithmicoutput]}
57
58 \newcommand{\TOLG}{\mathit{tol_{gmres}}}
59 \newcommand{\MIG}{\mathit{maxit_{gmres}}}
60 \newcommand{\TOLM}{\mathit{tol_{multi}}}
61 \newcommand{\MIM}{\mathit{maxit_{multi}}}
62 \newcommand{\TOLC}{\mathit{tol_{cgls}}}
63 \newcommand{\MIC}{\mathit{maxit_{cgls}}}
64
65 \usepackage{array}
66 \usepackage{color, colortbl}
67 \newcolumntype{M}[1]{>{\centering\arraybackslash}m{#1}}
68 \newcolumntype{Z}[1]{>{\raggedleft}m{#1}}
69
70 \newcolumntype{g}{>{\columncolor{Gray}}c}
71 \definecolor{Gray}{gray}{0.9}
72
73
74
75 \begin{document}
76 \title{Grid-enabled simulation of large-scale linear iterative solvers}
77 %\itshape{\journalnamelc}\footnotemark[2]}
78
79 \author{Charles Emile Ramamonjisoa\affil{1},
80     David Laiymani\affil{1},
81     Arnaud Giersch\affil{1},
82     Lilia Ziane Khodja\affil{2} and
83     Raphaël Couturier\affil{1}
84 }
85
86 \address{
87   \affilnum{1}%
88   Femto-ST Institute, DISC Department,
89   University of Franche-Comté,
90   Belfort, France.
91   Email:~\email{{charles.ramamonjisoa,david.laiymani,arnaud.giersch,raphael.couturier}@univ-fcomte.fr}\break
92   \affilnum{2}
93   Department of Aerospace \& Mechanical Engineering,
94   Non Linear Computational Mechanics,
95   University of Liege, Liege, Belgium.
96   Email:~\email{l.zianekhodja@ulg.ac.be}
97 }
98
99 \begin{abstract} %% The behavior of multi-core applications is always a challenge
100 %% to predict, especially with a new architecture for which no experiment has been
101 %% performed. With some applications, it is difficult, if not impossible, to build
102 %% accurate performance models. That is why another solution is to use a simulation
103 %% tool which allows us to change many parameters of the architecture (network
104 %% bandwidth, latency, number of processors) and to simulate the execution of such
105 %% applications. The main contribution of this paper is to show that the use of a
106 %% simulation tool (here we have decided to use the SimGrid toolkit) can really
107 %% help developers to better tune their applications for a given multi-core
108 %% architecture.
109
110 %% In this paper we focus our attention on the simulation of iterative algorithms to solve sparse linear systems on large clusters. We study the behavior of the widely used GMRES algorithm and two different variants of the Multisplitting algorithms: one using synchronous iterations and another one with asynchronous iterations.  
111 %% For each algorithm we have simulated
112 %% different architecture parameters to evaluate their influence on the overall
113 %% execution time. 
114 %% The simulations confirm the real results previously obtained on different real multi-core architectures and also confirm the efficiency of the asynchronous Multisplitting algorithm on distant clusters compared to the synchronous GMRES algorithm.
115
116 The behavior of multi-core applications is always a challenge to predict, especially with a new architecture for which no experiment has been performed. With some applications, it is difficult, if not impossible, to build accurate performance models. That is why another solution is to use a simulation tool which allows us to change many parameters of the architecture (network bandwidth, latency, number of processors) and to simulate the execution of such applications. 
117
118 In this paper we focus on the simulation of iterative algorithms to solve sparse linear systems. We study the behavior of the GMRES algorithm and two different variants of the multisplitting algorithms: using synchronous or asynchronous iterations. For each algorithm we have simulated different architecture parameters to evaluate their influence on the overall execution time. The simulations confirm the real results previously obtained on different real multi-core architectures and also confirm the efficiency of the asynchronous multisplitting algorithm on distant clusters compared to the GMRES algorithm.
119
120 \end{abstract}
121
122 %\keywords{Algorithm; distributed; iterative; asynchronous; simulation; simgrid;
123 %performance}
124 \keywords{ Performance evaluation, Simulation, SimGrid,  Synchronous and asynchronous iterations, Multisplitting algorithms}
125
126 \maketitle
127
128 \section{Introduction}  The use of multi-core architectures to solve large
129 scientific problems seems to  become imperative  in  many situations.
130 Whatever the scale of these architectures (distributed clusters, computational
131 grids, embedded multi-core,~\ldots) they  are generally  well adapted to execute
132 complex parallel applications operating on a large amount of data.
133 Unfortunately,  users (industrials or scientists),  who need such computational
134 resources, may not have an easy access to such efficient architectures. The cost
135 of using the platform and/or the cost of  testing and deploying an application
136 are often very important. So, in this context it is difficult to optimize a
137 given application for a given  architecture. In this way and in order to reduce
138 the access cost to these computing resources it seems very interesting to use a
139 simulation environment.  The advantages are numerous: development life cycle,
140 code debugging, ability to obtain results quickly\dots{} In counterpart, the simulation results need to be consistent with the real ones.
141
142 In this paper we focus on a class of highly efficient parallel algorithms called
143 \emph{iterative algorithms}. The parallel scheme of iterative methods is quite
144 simple. It generally involves the division of the problem into  several
145 \emph{blocks}  that  will  be  solved  in  parallel  on  multiple processing
146 units.  Each processing unit has to compute an iteration to send/receive some
147 data dependencies to/from its neighbors and to iterate this process until the
148 convergence of the method. Several well-known studies demonstrate the
149 convergence of these algorithms~\cite{BT89,bahi07}. In this processing mode a
150 task cannot begin a new iteration while it has not received data dependencies
151 from its neighbors. We say that the iteration computation follows a
152 \textit{synchronous} scheme. In the asynchronous scheme a task can compute a new
153 iteration without having to wait for the data dependencies coming from its
154 neighbors. Both communications and computations are \textit{asynchronous}
155 inducing that there is no more idle time, due to synchronizations, between two
156 iterations~\cite{bcvc06:ij}. This model presents some advantages and drawbacks
157 that we detail in Section~\ref{sec:asynchro} but even if the number of
158 iterations required to converge is generally  greater  than for the synchronous
159 case, it appears that the asynchronous  iterative scheme  can significantly
160 reduce  overall execution times by  suppressing idle  times due to
161 synchronizations~(see~\cite{bahi07} for more details).
162
163 Nevertheless,  in both  cases  (synchronous  or asynchronous)  it  is very  time
164 consuming to find optimal configuration  and deployment requirements for a given
165 application  on   a  given   multi-core  architecture.  Finding   good  resource
166 allocations policies under  varying CPU power, network speeds and  loads is very
167 challenging and  labor intensive~\cite{Calheiros:2011:CTM:1951445.1951450}. This
168 problematic is  even more difficult  for the  asynchronous scheme where  a small
169 parameter variation of the execution platform and of the application data can
170 lead to very different numbers of iterations to reach the convergence and so to
171 very different execution times. In this challenging context we think that the
172 use of a simulation tool can greatly leverage the possibility of testing various
173 platform scenarios.
174
175 The  {\bf main  contribution  of  this paper}  is  to show  that  the  use of  a
176 simulation tool (i.e. the SimGrid toolkit~\cite{SimGrid}) in the context of real
177 parallel applications (i.e. large linear  system solvers) can help developers to
178 better tune their  applications for a given multi-core architecture.  To show the
179 validity of this approach we first compare the simulated execution of the Krylov
180 multisplitting  algorithm   with  the   GMRES  (Generalized   Minimal  RESidual)
181 solver~\cite{saad86} in  synchronous mode.  The simulation  results allow  us to
182 determine  which method  to choose  for a given multi-core  architecture.
183 Moreover the  obtained results  on different simulated  multi-core architectures
184 confirm the  real results  previously obtained  on non  simulated architectures.
185 More precisely the simulated results are in accordance (i.e. with the same order
186 of magnitude)  with the works  presented in~\cite{couturier15}, which  show that
187 the synchronous  Krylov multisplitting method  is more efficient  than GMRES  for large
188 scale  clusters.   Simulated   results  also  confirm  the   efficiency  of  the
189 asynchronous  multisplitting   algorithm  compared  to  the   synchronous  GMRES
190 especially in case of geographically distant clusters.
191
192 In this way and with a simple computing architecture (a laptop) SimGrid allows us
193 to run a test campaign  of  a  real parallel iterative  applications on
194 different simulated multi-core architectures.  To our knowledge, there is no
195 related work on the large-scale multi-core simulation of a real synchronous and
196 asynchronous iterative application.
197
198 This paper is organized as follows. Section~\ref{sec:asynchro} presents the
199 iteration model we use and more particularly the asynchronous scheme.  In
200 Section~\ref{sec:simgrid} the SimGrid simulation toolkit is presented.
201 Section~\ref{sec:04} details the different solvers that we use.  Finally our
202 experimental results are presented in Section~\ref{sec:expe} followed by some
203 concluding remarks and perspectives.
204
205
206 \section{The asynchronous iteration model and the motivations of our work}
207 \label{sec:asynchro}
208
209 Asynchronous iterative methods have been  studied for many years theoretically and
210 practically. Many methods have been considered and convergence results have been
211 proved. These  methods can  be used  to solve, in  parallel, fixed  point problems
212 (i.e. problems  for which  the solution is  $x^\star =f(x^\star)$.  In practice,
213 asynchronous iteration  methods can be used  to solve, for example,  linear and
214 non-linear systems of equations or optimization problems, interested readers are
215 invited to read~\cite{BT89,bahi07}.
216
217 Before  using  an  asynchronous  iterative   method,  the  convergence  must  be
218 studied. Otherwise, the  application is not ensure to reach  the convergence. An
219 algorithm that supports both the synchronous or the asynchronous iteration model
220 requires very few modifications  to be able to be executed  in both variants. In
221 practice, only  the communications and  convergence detection are  different. In
222 the synchronous  mode, iterations are  synchronized whereas in  the asynchronous
223 one, they are not.  It should be noticed that non-blocking communications can be
224 used in both  modes. Concerning the convergence  detection, synchronous variants
225 can use  a global convergence procedure  which acts as a  global synchronization
226 point. In the  asynchronous model, the convergence detection is  more tricky as
227 it   must  not   synchronize  all   the  processors.   Interested  readers   can
228 consult~\cite{myBCCV05c,bahi07,ccl09:ij}.
229
230 The number of iterations required to reach the convergence is generally greater
231 for the asynchronous scheme (this number depends on  the delay of the
232 messages). Note that, it is not the case in the synchronous mode where the
233 number of iterations is the same than in the sequential mode. In this way, the
234 set of the parameters  of the  platform (number  of nodes,  power of nodes,
235 inter and  intra clusters  bandwidth  and  latency,~\ldots) and  of  the
236 application can drastically change the number of iterations required to get the
237 convergence. It follows that asynchronous iterative algorithms are difficult to
238 optimize since the financial and deployment costs on large scale multi-core
239 architectures are often very important. So, prior to deployment and tests it
240 seems very promising to be able to simulate the behavior of asynchronous
241 iterative algorithms. The problematic is then to show that the results produced
242 by simulation are in accordance with reality i.e. of the same order of
243 magnitude. To our knowledge, there is no study on this problematic.
244
245 \section{SimGrid}
246 \label{sec:simgrid}
247 SimGrid~\cite{SimGrid,casanova+legrand+quinson.2008.simgrid,casanova+giersch+legrand+al.2014.versatile} is a discrete event simulation framework to study the behavior of large-scale distributed computing platforms as Grids, Peer-to-Peer systems, Clouds and High Performance Computation systems. It is widely used to simulate and evaluate heuristics, prototype applications or even assess legacy MPI applications. It is still actively developed by the scientific community and distributed as an open source software.
248
249 %%%%%%%%%%%%%%%%%%%%%%%%%
250 % SimGrid~\cite{SimGrid,casanova+legrand+quinson.2008.simgrid,casanova+giersch+legrand+al.2014.versatile}
251 % is a simulation framework to study the behavior of large-scale distributed
252 % systems.  As its name suggests, it emanates from the grid computing community,
253 % but is nowadays used to study grids, clouds, HPC or peer-to-peer systems.  The
254 % early versions of SimGrid date back from 1999, but it is still actively
255 % developed and distributed as an open source software.  Today, it is one of the
256 % major generic tools in the field of simulation for large-scale distributed
257 % systems.
258
259 SimGrid provides several programming interfaces: MSG to simulate Concurrent
260 Sequential Processes, SimDAG to simulate DAGs of (parallel) tasks, and SMPI to
261 run real applications written in MPI~\cite{MPI}.  Apart from the native C
262 interface, SimGrid provides bindings for the C++, Java, Lua and Ruby programming
263 languages.  SMPI is the interface that has been used for the work described in
264 this paper.  The SMPI interface implements about \np[\%]{80} of the MPI 2.0
265 standard~\cite{bedaride+degomme+genaud+al.2013.toward}, and supports
266 applications written in C or Fortran, with little or no modifications (cf Section IV - paragraph B).
267
268 Within SimGrid, the execution of a distributed application is simulated by a
269 single process.  The application code is really executed, but some operations,
270 like communications, are intercepted, and their running time is computed
271 according to the characteristics of the simulated execution platform.  The
272 description of this target platform is given as an input for the execution, by
273 means of an XML file.  It describes the properties of the platform, such as
274 the computing nodes with their computing power, the interconnection links with
275 their bandwidth and latency, and the routing strategy.  The scheduling of the
276 simulated processes, as well as the simulated running time of the application
277 are computed according to these properties.
278
279 To compute the durations of the operations in the simulated world, and to take
280 into account resource sharing (e.g. bandwidth sharing between competing
281 communications), SimGrid uses a fluid model.  This allows users to run relatively fast
282 simulations, while still keeping accurate
283 results~\cite{bedaride+degomme+genaud+al.2013.toward,
284   velho+schnorr+casanova+al.2013.validity}.  Moreover, depending on the
285 simulated application, SimGrid/SMPI allows to skip long lasting computations and
286 to only take their duration into account.  When the real computations cannot be
287 skipped, but the results are unimportant for the simulation results, it is
288 also possible to share dynamically allocated data structures between
289 several simulated processes, and thus to reduce the whole memory consumption.
290 These two techniques can help to run simulations on a very large scale.
291
292 The validity of simulations with SimGrid has been asserted by several studies.
293 See, for example, \cite{velho+schnorr+casanova+al.2013.validity} and articles
294 referenced therein for the validity of the network models.  Comparisons between
295 real execution of MPI applications on the one hand, and their simulation with
296 SMPI on the other hand, are presented in~\cite{guermouche+renard.2010.first,
297   clauss+stillwell+genaud+al.2011.single,
298   bedaride+degomme+genaud+al.2013.toward}.  All these works conclude that
299 SimGrid is able to simulate pretty accurately the real behavior of the
300 applications.
301 %%%%%%%%%%%%%%%%%%%%%%%%%
302
303 \section{Two-stage multisplitting methods}
304 \label{sec:04}
305 \subsection{Synchronous and asynchronous two-stage methods for sparse linear systems}
306 \label{sec:04.01}
307 In this paper we focus on two-stage multisplitting methods in their both versions (synchronous and asynchronous)~\cite{Frommer92,Szyld92,Bru95}. These iterative methods are based on multisplitting methods~\cite{O'leary85,White86,Alefeld97} and use two nested iterations: the outer iteration and the inner iteration. Let us consider the following sparse linear system of $n$ equations in $\mathbb{R}$:
308 \begin{equation}
309 Ax=b,
310 \label{eq:01}
311 \end{equation}
312 where $A$ is a sparse square and nonsingular matrix, $b$ is the right-hand side and $x$ is the solution of the system. Our work in this paper is restricted to the block Jacobi splitting method. This approach of multisplitting consists in partitioning the matrix $A$ into $L$ horizontal band matrices of order $\frac{n}{L}\times n$ without overlapping (i.e. sub-vectors $\{x_\ell\}_{1\leq\ell\leq L}$ are disjoint). Two-stage multisplitting methods solve the linear system~(\ref{eq:01}) iteratively as follows:
313 \begin{equation}
314 x_\ell^{k+1} = A_{\ell\ell}^{-1}(b_\ell - \displaystyle\sum^{L}_{\substack{m=1\\m\neq\ell}}{A_{\ell m}x^k_m}),\mbox{~for~}\ell=1,\ldots,L\mbox{~and~}k=1,2,3,\ldots
315 \label{eq:02}
316 \end{equation}
317 where $x_\ell$ are sub-vectors of the solution $x$, $b_\ell$ are the sub-vectors of the right-hand side $b$, and $A_{\ell\ell}$ and $A_{\ell m}$ are diagonal and off-diagonal blocks of matrix $A$ respectively. The iterations of these methods can naturally be computed in parallel such that each processor or cluster of processors is responsible for solving one splitting as a linear sub-system:
318 \begin{equation}
319 A_{\ell\ell} x_\ell = c_\ell,\mbox{~for~}\ell=1,\ldots,L,
320 \label{eq:03}
321 \end{equation}
322 where right-hand sides $c_\ell=b_\ell-\sum_{m\neq\ell}A_{\ell m}x_m$ are computed using the shared vectors $x_m$. In this paper, we use the well-known iterative method GMRES~\cite{saad86} as an inner iteration to approximate the solutions of the different splittings arising from the block Jacobi multisplitting of matrix $A$. The algorithm in Figure~\ref{alg:01} shows the main key points of our block Jacobi two-stage method executed by a cluster of processors. In line~\ref{solve}, the linear sub-system~(\ref{eq:03}) is solved in parallel using GMRES method where $\MIG$ and $\TOLG$ are the maximum number of inner iterations and the tolerance threshold for GMRES respectively. The convergence of the two-stage multisplitting methods, based on synchronous or asynchronous iterations, has been studied by many authors for example~\cite{Bru95,bahi07}.
323
324 \begin{figure}[htpb]
325 %\begin{algorithm}[t]
326 %\caption{Block Jacobi two-stage multisplitting method}
327 \begin{algorithmic}[1]
328   \Input $A_\ell$ (sparse matrix), $b_\ell$ (right-hand side)
329   \Output $x_\ell$ (solution vector)\vspace{0.2cm}
330   \State Set the initial guess $x^0$
331   \For {$k=1,2,3,\ldots$ until convergence}
332     \State $c_\ell=b_\ell-\sum_{m\neq\ell}A_{\ell m}x_m^{k-1}$
333     \State $x^k_\ell=Solve_{gmres}(A_{\ell\ell},c_\ell,x^{k-1}_\ell,\MIG,\TOLG)$\label{solve}
334     \State Send $x_\ell^k$ to neighboring clusters\label{send}
335     \State Receive $\{x_m^k\}_{m\neq\ell}$ from neighboring clusters\label{recv}
336   \EndFor
337 \end{algorithmic}
338 \caption{Block Jacobi two-stage multisplitting method}
339 \label{alg:01}
340 %\end{algorithm}
341 \end{figure}
342
343 In this paper, we propose two algorithms of two-stage multisplitting methods. The first algorithm is based on the asynchronous model which allows communications to be overlapped by computations and reduces the idle times resulting from the synchronizations. So in the asynchronous mode, our two-stage algorithm uses asynchronous outer iterations and asynchronous communications between clusters. The communications (i.e. lines~\ref{send} and~\ref{recv} in Figure~\ref{alg:01}) are performed by message passing using MPI non-blocking communication routines. The convergence of the asynchronous iterations is detected when all clusters have locally converged:
344 \begin{equation}
345 k\geq\MIM\mbox{~or~}\|x_\ell^{k+1}-x_\ell^k\|_{\infty }\leq\TOLM,
346 \label{eq:04}
347 \end{equation}
348 where $\MIM$ is the maximum number of outer iterations and $\TOLM$ is the tolerance threshold for the two-stage algorithm.
349
350 The second two-stage algorithm is based on synchronous outer iterations. We propose to use the Krylov iteration based on residual minimization to improve the slow convergence of the multisplitting methods. In this case, a $n\times s$ matrix $S$ is set using solutions issued from the inner iteration:
351 \begin{equation}
352 S=[x^1,x^2,\ldots,x^s],~s\ll n.
353 \label{eq:05}
354 \end{equation}
355 At each $s$ outer iterations, the algorithm computes a new approximation $\tilde{x}=S\alpha$ which minimizes the residual:
356 \begin{equation}
357 \min_{\alpha\in\mathbb{R}^s}{\|b-AS\alpha\|_2}.
358 \label{eq:06}
359 \end{equation}
360 The algorithm in Figure~\ref{alg:02} includes the procedure of the residual minimization and the outer iteration is restarted with a new approximation $\tilde{x}$ at every $s$ iterations. The least-squares problem~(\ref{eq:06}) is solved in parallel by all clusters using CGLS method~\cite{Hestenes52} such that $\MIC$ is the maximum number of iterations and $\TOLC$ is the tolerance threshold for this method (line~\ref{cgls} in Figure~\ref{alg:02}).
361
362 \begin{figure}[htbp]
363 %\begin{algorithm}[t]
364 %\caption{Krylov two-stage method using block Jacobi multisplitting}
365 \begin{algorithmic}[1]
366   \Input $A_\ell$ (sparse matrix), $b_\ell$ (right-hand side)
367   \Output $x_\ell$ (solution vector)\vspace{0.2cm}
368   \State Set the initial guess $x^0$
369   \For {$k=1,2,3,\ldots$ until convergence}
370     \State $c_\ell=b_\ell-\sum_{m\neq\ell}A_{\ell m}x_m^{k-1}$
371     \State $x^k_\ell=Solve_{gmres}(A_{\ell\ell},c_\ell,x^{k-1}_\ell,\MIG,\TOLG)$
372     \State $S_{\ell,k\mod s}=x_\ell^k$
373     \If{$k\mod s = 0$}
374        \State $\alpha = Solve_{cgls}(AS,b,\MIC,\TOLC)$\label{cgls}
375        \State $\tilde{x_\ell}=S_\ell\alpha$
376        \State Send $\tilde{x_\ell}$ to neighboring clusters
377        \Else
378          \State Send $x_\ell^k$ to neighboring clusters
379     \EndIf
380     \State Receive $\{x_m^k\}_{m\neq\ell}$ from neighboring clusters
381   \EndFor
382 \end{algorithmic}
383 \caption{Krylov two-stage method using block Jacobi multisplitting}
384 \label{alg:02}
385 %\end{algorithm}
386 \end{figure}
387
388 \subsection{Simulation of the two-stage methods using SimGrid toolkit}
389 \label{sec:04.02}
390
391 One of our objectives when simulating the  application in SimGrid is, as in real
392 life, to  get accurate results  (solutions of the  problem) but also to ensure the
393 test reproducibility  under the same  conditions.  According to  our experience,
394 very  few modifications  are required  to adapt  a MPI  program for  the SimGrid
395 simulator using SMPI (Simulator MPI). The  first modification is to include SMPI
396 libraries  and related  header files  (\verb+smpi.h+).  The  second modification  is to
397 suppress all global variables by replacing  them with local variables or using a
398 SimGrid selector       called      "runtime       automatic      switching"
399 (smpi/privatize\_global\_variables). Indeed, global  variables can generate side
400 effects on runtime between the threads running in the same process and generated by
401 SimGrid  to simulate the  grid environment.
402
403 \paragraph{Parameters of the simulation in SimGrid}
404 \  \\ \noindent  Before running  a SimGrid  benchmark, many  parameters for  the
405 computation platform must be defined. For our experiments, we consider platforms
406 in which  several clusters are  geographically distant,  so there are  intra and
407 inter-cluster communications. In the following, these parameters are described:
408
409 \begin{itemize}
410         \item hostfile: hosts description file,
411         \item platform: file describing the platform architecture: clusters (CPU power,
412 \dots{}), intra cluster network description, inter cluster network (bandwidth $bw$,
413 latency $lat$, \dots{}),
414         \item archi   : grid computational description (number of clusters, number of
415 nodes/processors in each cluster).
416 \end{itemize}
417 \noindent
418 In addition, the following arguments are given to the programs at runtime:
419
420 \begin{itemize}
421         \item maximum number of inner iterations $\MIG$ and outer iterations $\MIM$,
422         \item inner precision $\TOLG$ and outer precision $\TOLM$,
423         \item matrix sizes of the problem: N$_{x}$, N$_{y}$ and N$_{z}$ on axis $x$, $y$ and $z$ respectively (in our experiments, we solve 3D problem, see Section~\ref{3dpoisson}),
424         \item matrix diagonal value is fixed to $6.0$ for synchronous experiments and $6.2$ for asynchronous ones,
425         \item matrix off-diagonal value is fixed to $-1.0$,
426         \item number of vectors in matrix $S$ (i.e. value of $s$),
427         \item maximum number of iterations $\MIC$ and precision $\TOLC$ for CGLS method,
428         \item maximum number of iterations and precision for the classical GMRES method,
429         \item maximum number of restarts for the Arnorldi process in GMRES method,
430         \item execution mode: synchronous or asynchronous.
431 \end{itemize}
432
433 It should also be noticed that both solvers have been executed with the SimGrid selector \texttt{-cfg=smpi/running\_power} which determines the computational power (here 19GFlops) of the simulator host machine.
434
435 %%%%%%%%%%%%%%%%%%%%%%%%%
436 %%%%%%%%%%%%%%%%%%%%%%%%%
437
438 \section{Experimental results}
439 \label{sec:expe}
440
441 In this section, experiments for both multisplitting algorithms are reported. First the 3D Poisson problem used in our experiments is described.
442
443 \subsection{The 3D Poisson problem}
444 \label{3dpoisson}
445 We use our two-stage algorithms to solve the well-known Poisson problem $\nabla^2\phi=f$~\cite{Polyanin01}. In three-dimensional Cartesian coordinates in $\mathbb{R}^3$, the problem takes the following form:
446 \begin{equation}
447 \frac{\partial^2}{\partial x^2}\phi(x,y,z)+\frac{\partial^2}{\partial y^2}\phi(x,y,z)+\frac{\partial^2}{\partial z^2}\phi(x,y,z)=f(x,y,z)\mbox{~in the domain~}\Omega
448 \label{eq:07}
449 \end{equation}
450 such that:
451 \begin{equation*}
452 \phi(x,y,z)=0\mbox{~on the boundary~}\partial\Omega
453 \end{equation*}
454 where the real-valued function $\phi(x,y,z)$ is the solution sought, $f(x,y,z)$ is a known function and $\Omega=[0,1]^3$. The 3D discretization of the Laplace operator $\nabla^2$ with the finite difference scheme includes 7 points stencil on the computational grid. The numerical approximation of the Poisson problem on three-dimensional grid is repeatedly computed as $\phi=\phi^\star$ such that:
455 \begin{equation}
456 \begin{array}{ll}
457 \phi^\star(x,y,z)=&\frac{1}{6}(\phi(x-h,y,z)+\phi(x,y-h,z)+\phi(x,y,z-h)\\&+\phi(x+h,y,z)+\phi(x,y+h,z)+\phi(x,y,z+h)\\&-h^2f(x,y,z))
458 \end{array}
459 \label{eq:08}
460 \end{equation}
461 until convergence where $h$ is the grid spacing between two adjacent elements in the 3D computational grid.
462
463 In the parallel context, the 3D Poisson problem is partitioned into $L\times p$ sub-problems such that $L$ is the number of clusters and $p$ is the number of processors in each cluster. We apply the three-dimensional partitioning instead of the row-by-row one in order to reduce the size of the data shared at the sub-problems boundaries. In this case, each processor is in charge of parallelepipedic block of the problem and has at most six neighbors in the same cluster or in distant clusters with which it shares data at boundaries.
464
465 \subsection{Study setup and simulation methodology}
466
467 First, to conduct our study, we propose the following methodology
468 which can be reused for any grid-enabled applications.\\
469
470 \textbf{Step 1}: Choose with the end users the class of algorithms or
471 the application to be tested. Numerical parallel iterative algorithms
472 have been chosen for the study in this paper. \\
473
474 \textbf{Step 2}: Collect the software materials needed for the experimentation.
475 In our case, we have two variants algorithms for the resolution of the
476 3D-Poisson problem: (1) using the classical GMRES; (2) and the multisplitting
477 method. In addition, the SimGrid simulator has been chosen to simulate the
478 behaviors of the distributed applications. SimGrid is running in a virtual
479 machine on a simple laptop. \\
480
481 \textbf{Step 3}: Fix the criteria which will be used for the future
482 results comparison and analysis. In the scope of this study, we retain
483 on the  one hand the algorithm execution mode (synchronous and asynchronous)
484 and on the other hand the execution time and the number of iterations to reach the convergence. \\
485
486 \textbf{Step 4}: Set up the  different grid testbed environments  that will be
487 simulated in the  simulator tool to run the program.  The following architectures
488 have been configured in SimGrid : 2$\times$16, 4$\times$8, 4$\times$16, 8$\times$8 and 2$\times$50. The first number
489 represents the number  of clusters in the grid and  the second number represents
490 the number  of hosts (processors/cores)  in each  cluster. \\
491
492 \textbf{Step 5}: Conduct an extensive and comprehensive testings
493 within these configurations by varying the key parameters, especially
494 the CPU power capacity, the network parameters and also the size of the
495 input data.  \\
496
497 \textbf{Step 6} : Collect and analyze the output results.
498
499 \subsection{Factors impacting distributed applications performance in a grid environment}
500
501 When running a distributed application in a computational grid, many factors may
502 have a strong impact on the performance.  First of all, the architecture of the
503 grid itself can obviously influence the  performance results of the program. The
504 performance gain  might be important  theoretically when the number  of clusters
505 and/or  the  number  of  nodes (processors/cores)  in  each  individual  cluster
506 increase.
507
508 Another important factor  impacting the overall performance  of the application
509 is the network configuration. Two main network parameters can modify drastically
510 the program output results:
511 \begin{enumerate}
512 \item  the network  bandwidth  ($bw$ in bits/s) also  known  as "the  data-carrying
513     capacity" of the network is defined as  the maximum of data that can transit
514     from one point to another in a unit of time.
515 \item the  network latency  ($lat$ in microseconds) defined as  the delay  from the
516   start time to send  a simple data from a source to a destination.
517 \end{enumerate}
518 Upon  the   network  characteristics,  another  impacting   factor  is  the volume of data exchanged  between the nodes in the cluster
519 and  between distant  clusters.  This parameter is application dependent.
520
521  In  a grid  environment, it  is common  to distinguish,  on the  one hand,  the
522  "intra-network" which refers  to the links between nodes within  a cluster and
523  on  the other  hand, the  "inter-network" which  is the  backbone link  between
524  clusters.  In   practice,  these  two   networks  have  different   speeds.
525  The intra-network  generally works  like a  high speed  local network  with a
526  high bandwidth and very low latency. In opposite, the inter-network connects
527  clusters sometime via  heterogeneous networks components  through internet with
528  a lower speed.  The network  between distant  clusters might  be a  bottleneck
529  for  the global performance of the application.
530
531
532 \subsection{Comparison between GMRES and two-stage multisplitting algorithms in synchronous mode}
533 In the scope of this paper, our first objective is to analyze when the synchronous Krylov two-stage method has better performance than the classical GMRES method. With a synchronous iterative method, better performance means a smaller number of iterations and execution time before reaching the convergence.
534
535 Table~\ref{tab:01} summarizes the parameters used in the different simulations: the grid architectures, the network of inter-clusters backbone links and the matrix sizes of the 3D Poisson problem. However, for all simulations we fix the network parameters of the intra-clusters links: the bandwidth $bw$=10Gbs and the latency $lat$=8$\times$10$^{-6}$. In what follows, we will present the test conditions, the output results and our comments. 
536
537 \begin{table} [ht!]
538 \begin{center}
539 \begin{tabular}{ll}
540 \hline
541 Grid architecture                       & 2$\times$16, 4$\times$8, 4$\times$16 and 8$\times$8\\ 
542 \multirow{2}{*}{Network inter-clusters} & $N1$: $bw$=1Gbs, $lat$=5$\times$10$^{-5}$ \\ 
543                                         & $N2$: $bw$=10Gbs, $lat$=8$\times$10$^{-6}$ \\
544 \multirow{2}{*}{Matrix size}            & $Mat1$: N$_{x}\times$N$_{y}\times$N$_{z}$=150$\times$150$\times$150\\
545                                         & $Mat2$: N$_{x}\times$N$_{y}\times$N$_{z}$=170$\times$170$\times$170 \\ \hline
546 \end{tabular}
547 \caption{Parameters for the different simulations}
548 \label{tab:01}
549 \end{center}
550 \end{table}
551
552 \subsubsection{Simulations for various grid architectures and scaling-up matrix sizes}
553 \  \\
554 % environment
555 In this section, we analyze the simulations conducted on various grid configurations and for different sizes of the 3D Poisson problem. The parameters of the network between clusters is fixed to $N1$ (see Table~\ref{tab:01}. Figure~\ref{fig:01} shows, for all grid configurations and a given matrix size 170$^3$ elements, a non-variation in the number of iterations for the classical GMRES algorithm, which is not the case of the Krylov two-stage algorithm.
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583 \begin{figure} [htbp]
584   \begin{center}
585     \includegraphics[width=100mm]{cluster_x_nodes_nx_150_and_nx_170.pdf}
586   \end{center}
587   \caption{Various grid configurations with the matrix sizes 150$^3$ and 170$^3$}
588 %\AG{Utiliser le point comme séparateur décimal et non la virgule.  Idem dans les autres figures.}
589 %\LZK{Pour quelle taille du problème sont calculés les nombres d'itérations? Que représente le 2 Clusters x 16 Nodes with Nx=150 and Nx=170 en haut de la figure?}
590   %\RCE {Corrige}
591     \RC{Idéalement dans la légende il faudrait insiquer Pb size=$150^3$ ou $170^3$  car pour l'instant Nx=150 ca n'indique rien concernant Ny et Nz}
592   \label{fig:01}
593 \end{figure}
594
595
596
597 The execution  times between  the two algorithms  is significant  with different
598 grid architectures, even  with the same number of processors  (for example, 2 $\times$ 16
599 and  4 $\times  8$). We  can  observe  a better  sensitivity  of  the Krylov multisplitting  method
600 (compared with the classical GMRES) when scaling up the number of the processors
601 in the  grid: in  average, the GMRES  (resp. Multisplitting)  algorithm performs
602 $40\%$ better (resp. $48\%$) when running from 32 (grid 2 $\times$ 16) to 64 processors/cores (grid 8 $\times$ 8). Note that even with a grid 8 $\times$ 8 having the maximum number of clusters, the execution time of the multisplitting method is in average 32\% less compared to GMRES. 
603 \RC{pas très clair, c'est pas précis de dire qu'un algo perform mieux qu'un autre, selon quel critère?}
604 \LZK{A revoir toute cette analyse... Le multi est plus performant que GMRES. Les temps d'exécution de multi sont sensibles au nombre de CLUSTERS. Il est moins performant pour un nombre grand de cluster. Avez vous d'autres remarques?}
605 \RCE{Remarquez que meme avec une grille 8x8, le multi est toujours plus performant}
606
607 \subsubsection{Simulations for two different inter-clusters network speeds \\}
608
609 \begin{table} [ht!]
610 \begin{center}
611 \begin{tabular}{ll}
612  \hline
613  Grid architecture        & 2$\times$16, 4$\times$8\\ %\hline
614  \multirow{2}{*}{Inter Network} & N1: $bw$=1Gbs, $lat$=5$\times$10$^{-5}$ \\ %\hline
615                           & N2: $bw$=10Gbs, $lat$=8$\times$10$^{-6}$ \\
616  Matrix size              & $N_{x} \times N_{y} \times N_{z} =150 \times 150 \times 150$\\ \hline
617  \end{tabular}
618 \caption{Test conditions: grid configurations 2$\times$16 and 4$\times$8 with networks N1 vs. N2}
619 \label{tab:02}
620 \end{center}
621 \end{table}
622
623 In this section, the experiments  compare the  behavior of  the algorithms  running on a
624 speeder inter-cluster  network (N2) and  also on  a less performant  network (N1) respectively defined in the test conditions Table~\ref{tab:02}.
625 %\RC{Il faut définir cela avant...}
626 Figure~\ref{fig:02} shows that end users will reduce the execution time
627 for  both  algorithms when using  a  grid  architecture  like  4 $\times$ 16 or  8 $\times$ 8: the reduction factor is around $2$. The results depict  also that when
628 the  network speed  drops down (variation of 12.5\%), the  difference between  the two Multisplitting algorithms execution times can reach more than 25\%.
629
630
631
632 %\begin{wrapfigure}{l}{100mm}
633 \begin{figure} [htbp]
634 \centering
635 \includegraphics[width=100mm]{cluster_x_nodes_n1_x_n2.pdf}
636 \caption{Various grid configurations with networks N1 vs N2}
637 %\AG{\np{8E-6}, \np{5E-6} au lieu de 8E-6, 5E-6}}
638 %\RCE{Corrige}
639 \label{fig:02}
640 \end{figure}
641 %\end{wrapfigure}
642
643
644 \subsubsection{Network latency impacts on performance}
645 \ \\
646 \begin{table} [ht!]
647 \centering
648 \begin{tabular}{r c }
649  \hline
650  Grid Architecture & 2 $\times$ 16\\ %\hline
651  \multirow{2}{*}{Inter Network N1} & $bw$=1Gbs, \\ %\hline
652                           & $lat$= From 8$\times$10$^{-6}$ to  $6.10^{-5}$ second \\
653  Input matrix size & $N_{x} \times N_{y} \times N_{z} = 150 \times 150 \times 150$\\ \hline
654  \end{tabular}
655 \caption{Test conditions: network latency impacts}
656 \label{tab:03}
657 \end{table}
658
659 \begin{figure} [htbp]
660 \centering
661 \includegraphics[width=100mm]{network_latency_impact_on_execution_time.pdf}
662 \caption{Network latency impacts on execution time}
663 %\AG{\np{E-6}}}
664 \label{fig:03}
665 \end{figure}
666
667 In Table~\ref{tab:03}, parameters  for the influence of the  network latency are
668 reported.  According to the results of Figure~\ref{fig:03}, a degradation of the
669 network  latency  from  $8.10^{-6}$  to $6.10^{-5}$  implies  an  absolute  time
670 increase of more than $75\%$ (resp.   $82\%$) of the execution for the classical
671 GMRES  (resp.   Krylov  multisplitting)  algorithm. The  execution  time  factor
672 between the two algorithms  varies from 2.2 to 1.5 times  with a network latency
673 decreasing from $8.10^{-6}$ to $6.10^{-5}$.
674
675
676 \subsubsection{Network bandwidth impacts on performance}
677 \ \\
678 \begin{table} [ht!]
679 \centering
680 \begin{tabular}{r c }
681  \hline
682  Grid Architecture & 2 $\times$ 16\\ %\hline
683 \multirow{2}{*}{Inter Network N1} & $bw$=From 1Gbs to 10 Gbs \\ %\hline
684                           & $lat$= 5.10$^{-5}$ second \\
685  Input matrix size & $N_{x} \times N_{y} \times N_{z} =150 \times 150 \times 150$\\ \hline \\
686  \end{tabular}
687 \caption{Test conditions: Network bandwidth impacts}
688 %  \RC{Qu'est ce qui varie ici? Il n'y a pas de variation dans le tableau}
689 %\RCE{C est le bw}
690 \label{tab:04}
691 \end{table}
692
693
694 \begin{figure} [htbp]
695 \centering
696 \includegraphics[width=100mm]{network_bandwith_impact_on_execution_time.pdf}
697 \caption{Network bandwith impacts on execution time}
698 %\AG{``Execution time'' avec un 't' minuscule}. Idem autres figures.}
699 %\RCE{Corrige}
700 \label{fig:04}
701 \end{figure}
702
703 The results  of increasing  the network  bandwidth show  the improvement  of the
704 performance  for   both  algorithms   by  reducing   the  execution   time  (see
705 Figure~\ref{fig:04}). However,  in this  case, the Krylov  multisplitting method
706 presents a better  performance in the considered bandwidth interval  with a gain
707 of $40\%$ which is only around $24\%$ for the classical GMRES.
708
709 \subsubsection{Input matrix size impacts on performance}
710 \ \\
711 \begin{table} [ht!]
712 \centering
713 \begin{tabular}{r c }
714  \hline
715  Grid Architecture & 4 $\times$ 8\\ %\hline
716  Inter Network & $bw$=1Gbs - $lat$=5.10$^{-5}$ \\
717  Input matrix size & $N_{x} \times N_{y} \times N_{z}$ = From 50$^{3}$ to 190$^{3}$\\ \hline
718  \end{tabular}
719 \caption{Test conditions: Input matrix size impacts}
720 \label{tab:05}
721 \end{table}
722
723
724 \begin{figure} [htbp]
725 \centering
726 \includegraphics[width=100mm]{pb_size_impact_on_execution_time.pdf}
727 \caption{Problem size impacts on execution time}
728 \label{fig:05}
729 \end{figure}
730
731 In  these  experiments, the  input  matrix  size has  been  set  from $50^3$  to
732 $190^3$. Obviously, as shown in Figure~\ref{fig:05}, the execution time for both
733 algorithms increases when the input matrix size also increases.  For all problem
734 sizes, GMRES is always slower than the Krylov multisplitting. Moreover, for this
735 benchmark, it seems that  the greater the problem size is,  the bigger the ratio
736 between both  algorithm execution  times is.  We can also  observ that  for some
737 problem   sizes,  the   Krylov   multisplitting  convergence   varies  quite   a
738 lot. Consequently the execution times in that cases also varies.
739
740
741 These  findings may  help a  lot end  users to  setup the  best and  the optimal
742 targeted environment for the application deployment when focusing on the problem
743 size scale up.  It  should be noticed that the same test has  been done with the
744 grid 2 $\times$ 16 leading to the same conclusion.
745
746 \subsubsection{CPU Power impacts on performance}
747
748 \begin{table} [htbp]
749 \centering
750 \begin{tabular}{r c }
751  \hline
752  Grid architecture & 2 $\times$ 16\\ %\hline
753  Inter Network & N2 : $bw$=1Gbs - $lat$=5.10$^{-5}$ \\ %\hline
754  Input matrix size & $N_{x} = 150 \times 150 \times 150$\\ 
755  CPU Power & From 3 to 19 GFlops \\ \hline
756  \end{tabular}
757 \caption{Test conditions: CPU Power impacts}
758 \label{tab:06}
759 \end{table}
760
761 \begin{figure} [ht!]
762 \centering
763 \includegraphics[width=100mm]{cpu_power_impact_on_execution_time.pdf}
764 \caption{CPU Power impacts on execution time}
765 \label{fig:06}
766 \end{figure}
767
768 Using the Simgrid  simulator flexibility, we have tried to  determine the impact
769 on the  algorithms performance in  varying the CPU  power of the  clusters nodes
770 from $1$ to $19$ GFlops.  The outputs  depicted in Figure~\ref{fig:06}  confirm the
771 performance gain,  around $95\%$ for  both of the  two methods, after  adding more
772 powerful CPU.
773 \ \\
774 %\DL{il faut une conclusion sur ces tests : ils confirment les résultats déjà
775 %obtenus en grandeur réelle. Donc c'est une aide précieuse pour les dev. Pas
776 %besoin de déployer sur une archi réelle}
777
778 To conclude these series of experiments, with  SimGrid we have been able to make
779 many simulations  with many parameters  variations. Doing all  these experiments
780 with a real platform is most of  the time not possible. Moreover the behavior of
781 both GMRES and  Krylov multisplitting methods is in accordance  with larger real
782 executions on large scale supercomputer~\cite{couturier15}.
783
784
785 \subsection{Comparing GMRES in native synchronous mode and the multisplitting algorithm in asynchronous mode}
786
787 The previous paragraphs  put in evidence the interests to  simulate the behavior
788 of  the application  before  any  deployment in  a  real  environment.  In  this
789 section, following  the same previous  methodology, our  goal is to  compare the
790 efficiency of the multisplitting method  in \textit{ asynchronous mode} compared with the
791 classical GMRES in \textit{synchronous mode}.
792
793 The  interest of  using  an asynchronous  algorithm  is that  there  is no  more
794 synchronization. With  geographically distant  clusters, this may  be essential.
795 In  this case,  each  processor can  compute its  iteration  freely without  any
796 synchronization  with   the  other   processors.  Thus,  the   asynchronous  may
797 theoretically reduce  the overall execution  time and can improve  the algorithm
798 performance.
799
800 In this section,  the Simgrid simulator is  used to compare the  behavior of the
801 multisplitting in  asynchronous mode  with GMRES  in synchronous  mode.  Several
802 benchmarks have  been performed with  various combination of the  grid resources
803 (CPU, Network, input  matrix size, \ldots ). The test  conditions are summarized
804 in  Table~\ref{tab:07}. In  order to  compare  the execution  times, this  table
805 reports the  relative gain between both  algorithms. It is defined  by the ratio
806 between  the   execution  time  of   GMRES  and   the  execution  time   of  the
807 multisplitting.  The  ration  is  greater  than  one  because  the  asynchronous
808 multisplitting version is faster than GMRES.
809
810
811
812 \begin{table} [htbp]
813 \centering
814 \begin{tabular}{r c }
815  \hline
816  Grid Architecture & 2 $\times$ 50 totaling 100 processors\\ %\hline
817  Processors Power & 1 GFlops to 1.5 GFlops\\
818    Intra-Network & bw=1.25 Gbits - lat=5.10$^{-5}$ \\ %\hline
819    Inter-Network & bw=5 Mbits - lat=2.10$^{-2}$\\
820  Input matrix size & $N_{x}$ = From 62 to 150\\ %\hline
821  Residual error precision & 10$^{-5}$ to 10$^{-9}$\\ \hline \\
822  \end{tabular}
823 \caption{Test conditions: GMRES in synchronous mode vs Krylov Multisplitting in asynchronous mode}
824 \label{tab:07}
825 \end{table}
826
827 Again,  comprehensive and  extensive tests  have been  conducted with  different
828 parameters as  the CPU power, the  network parameters (bandwidth and  latency)
829 and with different problem size. The  relative gains greater than $1$  between the
830 two algorithms have  been captured after  each step  of the test.   In
831 Table~\ref{tab:08}  are  reported the  best  grid  configurations allowing
832 the  multisplitting method to  be more than  $2.5$ times faster  than the
833 classical  GMRES.  These  experiments also  show the  relative tolerance  of the
834 multisplitting algorithm when using a low speed network as usually observed with
835 geographically distant clusters through the internet.
836
837 % use the same column width for the following three tables
838 \newlength{\mytablew}\settowidth{\mytablew}{\footnotesize\np{E-11}}
839 \newenvironment{mytable}[1]{% #1: number of columns for data
840   \renewcommand{\arraystretch}{1.3}%
841   \begin{tabular}{|>{\bfseries}r%
842                   |*{#1}{>{\centering\arraybackslash}p{\mytablew}|}}}{%
843     \end{tabular}}
844
845
846 \begin{table}[!t]
847 \centering
848 %\begin{table}
849 %  \caption{Relative gain of the multisplitting algorithm compared with the classical GMRES}
850 %  \label{"Table 7"}
851  \begin{mytable}{11}
852     \hline
853     bandwidth (Mbit/s)
854     & 5     & 5     & 5         & 5         & 5  & 50        & 50        & 50        & 50        & 50 \\
855     \hline
856     latency (ms)
857     & 20      & 20      & 20      & 20      & 20 & 20      & 20      & 20      & 20      & 20 \\
858     \hline
859     power (GFlops)
860     & 1    & 1    & 1    & 1.5       & 1.5  & 1.5         & 1.5         & 1         & 1.5       & 1.5 \\
861     \hline
862     size ($N^3$)
863     & 62  & 62   & 62        & 100       & 100 & 110       & 120       & 130       & 140       & 150 \\
864     \hline
865     Precision
866     & \np{E-5}  & \np{E-8}  & \np{E-9}  & \np{E-11} & \np{E-11} & \np{E-11} & \np{E-11} & \np{E-11} & \np{E-11} & \np{E-11}\\
867     \hline
868     Relative gain
869     & 2.52     & 2.55     & 2.52     & 2.57     & 2.54 & 2.53     & 2.51     & 2.58     & 2.55     & 2.54 \\
870     \hline
871   \end{mytable}
872 %\end{table}
873  \caption{Relative gain of the multisplitting algorithm compared with the classical GMRES}
874  \label{tab:08}
875 \end{table}
876
877
878 \section{Conclusion}
879
880 In this paper we have presented the simulation of the execution of three
881 different parallel solvers on some multi-core architectures. We have show that
882 the SimGrid toolkit is an interesting simulation tool that has allowed us to
883 determine  which method  to choose  given a  specified multi-core  architecture.
884 Moreover the simulated results are in accordance (i.e. with the same order of
885 magnitude)  with the works  presented in~\cite{couturier15}. Simulated   results
886 also  confirm  the   efficiency  of  the asynchronous  multisplitting
887 algorithm  compared  to  the   synchronous  GMRES especially in case of
888 geographically distant clusters.
889
890 These results are important since it is very  time consuming to find optimal
891 configuration  and deployment requirements for a given application  on   a given
892 multi-core  architecture. Finding   good  resource allocations policies under
893 varying CPU power, network speeds and  loads is very challenging and  labor
894 intensive. This problematic is  even more difficult  for the  asynchronous
895 scheme where  a small parameter variation of the execution platform and of the
896 application data can lead to very different numbers of iterations to reach the
897 converge and so to very different execution times.
898
899
900 In future works, we  plan to investigate how to simulate  the behavior of really
901 large scale  applications. For  example, if  we are  interested to  simulate the
902 execution of the solvers of this paper with thousand or even dozens of thousands
903 or core,  it is not possible  to do that with  SimGrid. In fact, this  tool will
904 make the real computation. So we plan to focus our research on that problematic.
905
906
907
908 %\section*{Acknowledgment}
909 \ack
910 This work is partially funded by the Labex ACTION program (contract ANR-11-LABX-01-01).
911
912 \bibliographystyle{wileyj}
913 \bibliography{biblio}
914
915
916 \end{document}
917
918 %%% Local Variables:
919 %%% mode: latex
920 %%% TeX-master: t
921 %%% fill-column: 80
922 %%% ispell-local-dictionary: "american"
923 %%% End: