From a6eb13d9e879fac3b6ad0e97391bfea86b6c51a8 Mon Sep 17 00:00:00 2001 From: Arnaud Giersch Date: Wed, 7 May 2014 18:08:16 +0200 Subject: [PATCH] Spelling. --- hpcc.tex | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/hpcc.tex b/hpcc.tex index 83753da..9962b25 100644 --- a/hpcc.tex +++ b/hpcc.tex @@ -79,7 +79,7 @@ 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 -of asynchronous iterative algorithms. For that, we compare the behaviour of a +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 codes and simulations allow us to see when the asynchronous multisplitting algorithm can be more @@ -232,13 +232,13 @@ asynchronous iterative algorithms comes from the fact it is necessary to run the with real data. In fact, from an execution to another the order of messages will change and the number of iterations to reach the convergence will also change. According to all the parameters of the platform (number of nodes, power of -nodes, inter and intra clusrters bandwith and latency, etc.) and of the +nodes, inter and intra clusters bandwidth and latency, etc.) and of the algorithm (number of splittings with the multisplitting algorithm), the multisplitting code will obtain the solution more or less quickly. Of course, the GMRES method also depends of 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 -asynchronous iterative algoritms before being able to runs real experiments. +asynchronous iterative algorithms before being able to run real experiments. @@ -645,7 +645,9 @@ Note that the program was run with the following parameters: \begin{itemize} \item HOSTFILE: Text file containing the list of the processors units name. Here 100 hosts; -\item PLATFORM: XML file description of the platform architecture whith the following characteristics: %two clusters (cluster1 and cluster2) with the following characteristics : +\item PLATFORM: XML file description of the platform architecture with the + following characteristics: + % two clusters (cluster1 and cluster2) with the following characteristics: \begin{itemize} \item 2 clusters of 50 hosts each; \item Processor unit power: \np[GFlops]{1} or \np[GFlops]{1.5}; @@ -758,6 +760,6 @@ This work is partially funded by the Labex ACTION program (contract ANR-11-LABX- % LocalWords: Ouest Vieille Talence cedex scalability experimentations HPC MPI % LocalWords: Parallelization AIAC GMRES multi SMPI SISC SIAC SimDAG DAGs Lua % LocalWords: Fortran GFlops priori Mbit de du fcomte multisplitting scalable -% LocalWords: SimGrid Belfort parallelize Labex ANR LABX IEEEabrv hpccBib +% LocalWords: SimGrid Belfort parallelize Labex ANR LABX IEEEabrv hpccBib Gbit % LocalWords: intra durations nonsingular Waitall discretization discretized -% LocalWords: InnerSolver Isend Irecv +% LocalWords: InnerSolver Isend Irecv parallelization -- 2.39.5