From: Arnaud Giersch Date: Mon, 30 Jun 2014 13:44:03 +0000 (+0200) Subject: Easy corrections requested by reviewer #2. X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/hpcc2014.git/commitdiff_plain/a6da10e7e48efd0b0777c1dd25132fd4459b8219 Easy corrections requested by reviewer #2. --- diff --git a/hpcc.tex b/hpcc.tex index ec46af9..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. @@ -258,7 +258,7 @@ 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. @@ -268,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 @@ -485,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.