]> AND Private Git Repository - hpcc2014.git/blobdiff - hpcc.tex
Logo AND Algorithmique Numérique Distribuée

Private GIT Repository
v2
[hpcc2014.git] / hpcc.tex
index ab4fd27e6adaddec679f7baee731d5cf3033eba1..b2509c119c84cd4f4a25a59a14f7793db335008c 100644 (file)
--- 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
 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.
 
 
 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}.
 
 $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
 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,7 +228,7 @@ 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
 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
 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
@@ -518,7 +518,7 @@ $\text{62}^\text{3} = \text{\np{238328}}$ to $\text{150}^\text{3} =
     & 5         & 5         & 5         & 5         & 5         \\
     \hline
     latency (ms)
     & 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       \\
     \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)
     & 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 \\
     \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}
   
   \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.
 
 %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}
 %\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};
   \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}
 
   \end{itemize}
 \end{itemize}