X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/hpcc2014.git/blobdiff_plain/0bea9394eeb7dd6510ef86272dfe0aeeaf4cb4fc..71e9a817e3b9fe1daf0e108ff31cdbaba31197ff:/hpcc.tex?ds=sidebyside diff --git a/hpcc.tex b/hpcc.tex index ab4fd27..fdd60b2 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 @@ -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}