X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/hpcc2014.git/blobdiff_plain/0bea9394eeb7dd6510ef86272dfe0aeeaf4cb4fc..2f2f8237094c0e1c2d07da21054aafcc99672647:/hpcc.tex

diff --git a/hpcc.tex b/hpcc.tex
index ab4fd27..5559af7 100644
--- a/hpcc.tex
+++ b/hpcc.tex
@@ -83,7 +83,7 @@ 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
 synchronous  GMRES  algorithm  with  an  asynchronous  multisplitting  one  with
 simulations  which let us easily choose  some parameters.   Both  codes  are real  MPI
-codes ans simulations allow us to see when the asynchronous multisplitting algorithm can be more
+codes and simulations allow us to see when the asynchronous multisplitting algorithm can be more
 efficient than the GMRES one to solve a 3D Poisson problem.
 
 
@@ -103,7 +103,7 @@ suggests, these algorithms solve a given problem by successive iterations ($X_{n
 $X_{0}$ to find an approximate value $X^*$ of the solution with a very low residual error. Several well-known methods
 demonstrate the convergence of these algorithms~\cite{BT89,Bahi07}.
 
-Parallelization of such algorithms generally involve the division of the problem
+Parallelization of such algorithms generally involves the division of the problem
 into  several  \emph{blocks}  that  will  be  solved  in  parallel  on  multiple
 processing units. The latter will communicate each intermediate results before a
 new  iteration starts  and until  the  approximate solution  is reached.   These
@@ -228,13 +228,13 @@ In the context of asynchronous algorithms, the number of iterations to reach the
 convergence depends on  the delay of messages. With  synchronous iterations, the
 number of  iterations is exactly  the same than  in the sequential mode  (if the
 parallelization process does  not change the algorithm). So  the difficulty with
-asynchronous iteratie algorithms comes from the fact it is necessary to run the algorithm
+asynchronous iterative algorithms comes from the fact it is necessary to run the algorithm
 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,  ....) and  of  the
-algorithm  (number   of  splitting  with  the   multisplitting  algorithm),  the
-multisplitting code  will obtain the solution  more or less  quickly. Or course,
+nodes,  inter  and  intra clusrters  bandwith  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
@@ -518,7 +518,7 @@ $\text{62}^\text{3} = \text{\np{238328}}$ to $\text{150}^\text{3} =
     & 5         & 5         & 5         & 5         & 5         \\
     \hline
     latency (ms)
-    & 0.02      & 0.02      & 0.02      & 0.02      & 0.02      \\
+    & 20      &  20      & 20      & 20      & 20      \\
     \hline
     power (GFlops)
     & 1         & 1         & 1         & 1.5       & 1.5       \\
@@ -543,7 +543,7 @@ $\text{62}^\text{3} = \text{\np{238328}}$ to $\text{150}^\text{3} =
     & 50        & 50        & 50        & 50        & 50 \\ %       & 10        & 10 \\
     \hline
     latency (ms)
-    & 0.02      & 0.02      & 0.02      & 0.02      & 0.02 \\ %      & 0.03      & 0.01 \\
+    & 20      & 20      & 20      & 20      & 20 \\ %      & 0.03      & 0.01 \\
     \hline
     Power (GFlops)
     & 1.5       & 1.5       & 1.5       & 1.5       & 1.5 \\ %      & 1         & 1.5 \\
@@ -561,13 +561,15 @@ $\text{62}^\text{3} = \text{\np{238328}}$ to $\text{150}^\text{3} =
   \end{mytable}
 \end{table}
   
+\RC{Du coup la latence est toujours la même, pourquoi la mettre dans la table?}
+
 %Then we have changed the network configuration using three clusters containing
 %respectively 33, 33 and 34 hosts, or again by on hundred hosts for all the
 %clusters. In the same way as above, a judicious choice of key parameters has
 %permitted to get the results in Table~\ref{tab.cluster.3x33} which shows the
 %relative gains greater than 1 with a matrix size from 62 to 100 elements.
 
-\CER{En accord avec RC, on a pour le moment enlevé les tableaux 2 et 3 sachant que les résultats obtenus sont limites. De même, on a enlevé aussi les deux dernières colonnes du tableau I en attendant une meilleure performance et une meilleure precision}
+%\CER{En accord avec RC, on a pour le moment enlevé les tableaux 2 et 3 sachant que les résultats obtenus sont limites. De même, on a enlevé aussi les deux dernières colonnes du tableau I en attendant une meilleure performance et une meilleure precision}
 %\begin{table}[!t]
 %  \centering
 %  \caption{3 clusters, each with 33 nodes}
@@ -634,8 +636,8 @@ Note that the program was run with the following parameters:
   \begin{itemize}
   \item 2 clusters of 50 hosts each;
   \item Processor unit power: \np[GFlops]{1} or \np[GFlops]{1.5};
-  \item Intra-cluster network bandwidth: \np[Gbit/s]{1.25} and latency: \np[$\mu$s]{0.05};
-  \item Inter-cluster network bandwidth: \np[Mbit/s]{5} or \np[Mbit/s]{50} and latency: \np[$\mu$s]{20};
+  \item Intra-cluster network bandwidth: \np[Gbit/s]{1.25} and latency: \np[$\mu$s]{50};
+  \item Inter-cluster network bandwidth: \np[Mbit/s]{5} or \np[Mbit/s]{50} and latency: \np[ms]{20};
   \end{itemize}
 \end{itemize}