X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/hpcc2014.git/blobdiff_plain/1d2d441e1f8db7857168e78f9c56d599adb1c55e..2edc68548e4f3be75b5202d836bd8b320f762221:/hpcc.tex

diff --git a/hpcc.tex b/hpcc.tex
index 62922bc..4ff46b6 100644
--- a/hpcc.tex
+++ b/hpcc.tex
@@ -77,8 +77,8 @@ Synchronous  iterative  algorithms  are  often less  scalable  than  asynchronou
 iterative  ones.  Performing  large  scale experiments  with  different kind  of
 network parameters is not easy  because with supercomputers such parameters are
 fixed. So, one  solution consists in using simulations first  in order to analyze
-what parameters  could influence or not  the behaviors of an  algorithm. In this
-paper, we show  that it is interesting to use SimGrid  to simulate the behaviors
+what parameters  could influence or not  the behavior of an  algorithm. In this
+paper, we show  that it is interesting to use SimGrid  to simulate the behavior
 of asynchronous  iterative algorithms. For that,  we compare the  behavior of a
 synchronous  GMRES  algorithm  with  an  asynchronous  multisplitting  one  with
 simulations  which let us easily choose  some parameters.   Both  codes  are real  MPI
@@ -177,29 +177,29 @@ out will be presented before some concluding remarks and future works.
  
 \section{Motivations and scientific context}
 
-As exposed in  the introduction, parallel iterative methods  are now widely used
-in  many scientific  domains.   They can  be  classified in  three main  classes
-depending on  how iterations  and communications are  managed (for  more details
-readers  can refer  to~\cite{bcvc06:ij}). In  the synchronous  iterations model,
-data are exchanged  at the end of each iteration. All  the processors must begin
-the same iteration  at the same time and important idle  times on processors are
+As described in the introduction, parallel iterative methods are now widely used
+in many scientific domains.  They can be classified in three main classes
+depending on how iterations and communications are managed (for more details
+readers can refer to~\cite{bcvc06:ij}). In the synchronous iterations model,
+data are exchanged at the end of each iteration. All the processors must begin
+the same iteration at the same time and important idle times on processors are
 generated.  It is possible to use asynchronous communications, in this case, the
-model can be  compared to the previous one except that  data required on another
-processor are  sent asynchronously i.e.  without  stopping current computations.
-This technique  allows communications to be partially  overlapped by  computations but
-unfortunately, the overlapping is only  partial and important idle times remain.
-It is clear that, in a grid computing context, where the number of computational
-nodes is large,  heterogeneous and widely distributed, the  idle times generated
-by synchronizations are very penalizing. One  way to overcome this problem is to
-use the asynchronous iterations model.   Here, local computations do not need to
-wait for  required data. Processors can  then perform their  iterations with the
-data present  at that time.  Figure~\ref{fig:aiac} illustrates  this model where
-the gray blocks represent the  computation phases.  With this algorithmic model,
-the number  of iterations required  before the convergence is  generally greater
-than  for the  two former  classes.  But,  and as  detailed in~\cite{bcvc06:ij},
-asynchronous  iterative algorithms  can significantly  reduce  overall execution
-times by  suppressing idle  times due to  synchronizations especially in  a grid
-computing context.
+model can be compared to the previous one except that data required on another
+processor are sent asynchronously i.e.  without stopping current computations.
+This technique allows communications to be partially overlapped by computations
+but unfortunately, the overlapping is only partial and important idle times
+remain.  It is clear that, in a grid computing context, where the number of
+computational nodes is large, heterogeneous and widely distributed, the idle
+times generated by synchronizations are very penalizing. One way to overcome
+this problem is to use the asynchronous iterations model.  Here, local
+computations do not need to wait for required data. Processors can then perform
+their iterations with the data present at that time.  Figure~\ref{fig:aiac}
+illustrates this model where the gray blocks represent the computation phases.
+With this algorithmic model, the number of iterations required before the
+convergence is generally greater than for the two former classes.  But, and as
+detailed in~\cite{bcvc06:ij}, asynchronous iterative algorithms can
+significantly reduce overall execution times by suppressing idle times due to
+synchronizations especially in a grid computing context.
 
 \begin{figure}[!t]
   \centering
@@ -235,7 +235,7 @@ algorithm  (number   of  splittings  with  the   multisplitting  algorithm),  th
 multisplitting code  will obtain the solution  more or less  quickly. Of course,
 the GMRES method also depends on the same parameters. As it is difficult to have
 access to  many clusters,  grids or supercomputers  with many  different network
-parameters,  it  is  interesting  to  be  able  to  simulate  the  behaviors  of
+parameters,  it  is  interesting  to  be  able  to  simulate  the  behavior  of
 asynchronous iterative algorithms before being able to run real experiments.
 
 
@@ -245,19 +245,20 @@ asynchronous iterative algorithms before being able to run real experiments.
 
 \section{SimGrid}
 
-SimGrid~\cite{SimGrid,casanova+legrand+quinson.2008.simgrid} is a simulation
-framework to study the behavior of large-scale distributed systems.  As its name
-suggests, it emanates from the grid computing community, but is nowadays used to
-study grids, clouds, HPC or peer-to-peer systems.  The early versions of SimGrid
-date back from 1999, but it is still actively developed and distributed as an open
-source software.  Today, it is one of the major generic tools in the field of
-simulation for large-scale distributed systems.
+SimGrid~\cite{SimGrid,casanova+legrand+quinson.2008.simgrid,casanova+giersch+legrand+al.2014.versatile}
+is a simulation framework to study the behavior of large-scale distributed
+systems.  As its name suggests, it emanates from the grid computing community,
+but is nowadays used to study grids, clouds, HPC or peer-to-peer systems.  The
+early versions of SimGrid date back from 1999, but it is still actively
+developed and distributed as an open source software.  Today, it is one of the
+major generic tools in the field of simulation for large-scale distributed
+systems.
 
 SimGrid provides several programming interfaces: MSG to simulate Concurrent
 Sequential Processes, SimDAG to simulate DAGs of (parallel) tasks, and SMPI to
 run real applications written in MPI~\cite{MPI}.  Apart from the native C
 interface, SimGrid provides bindings for the C++, Java, Lua and Ruby programming
-languages.  SMPI is the interface that has been used for the work exposed in
+languages.  SMPI is the interface that has been used for the work described in
 this paper.  The SMPI interface implements about \np[\%]{80} of the MPI 2.0
 standard~\cite{bedaride+degomme+genaud+al.2013.toward}, and supports
 applications written in C or Fortran, with little or no modifications.
@@ -267,7 +268,7 @@ single process.  The application code is really executed, but some operations,
 like communications, are intercepted, and their running time is computed
 according to the characteristics of the simulated execution platform.  The
 description of this target platform is given as an input for the execution, by
-the mean of an XML file.  It describes the properties of the platform, such as
+means of an XML file.  It describes the properties of the platform, such as
 the computing nodes with their computing power, the interconnection links with
 their bandwidth and latency, and the routing strategy.  The scheduling of the
 simulated processes, as well as the simulated running time of the application
@@ -484,7 +485,7 @@ study that the results depend on the following parameters:
 \begin{itemize}
 \item At the network level, we found that the most critical values are the
   bandwidth and the network latency.
-\item Hosts processors power (GFlops) can also influence the results.
+\item Host processor power (GFlops) can also influence the results.
 \item Finally, when submitting job batches for execution, the arguments values
   passed to the program like the maximum number of iterations or the precision are critical. They allow us to ensure not only the convergence of the
   algorithm but also to get the main objective in getting an execution time with the asynchronous multisplitting  less than with synchronous GMRES. 
