X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/hpcc2014.git/blobdiff_plain/0ee56103583961f09e5ddf8299bfc1641416eb02..abc7ee50fcd018c2c756f80d084b182a712b245e:/hpcc.tex?ds=sidebyside diff --git a/hpcc.tex b/hpcc.tex index 15dd9d7..622a2f0 100644 --- a/hpcc.tex +++ b/hpcc.tex @@ -483,7 +483,7 @@ The ratio between the simulated execution time of synchronous GMRES algorithm compared to the asynchronous multisplitting algorithm ($t_\text{GMRES} / t_\text{Multisplitting}$) is defined as the \emph{relative gain}. So, our objective running the algorithm in SimGrid is to obtain a relative gain greater than 1. A priori, obtaining a relative gain greater than 1 would be difficult in a local -area network configuration where the synchronous mode will take advantage on the +area network configuration where the synchronous GMRES method will take advantage on the rapid exchange of information on such high-speed links. Thus, the methodology adopted was to launch the application on a clustered network. In this configuration, degrading the inter-cluster network performance will penalize the @@ -508,7 +508,8 @@ $\text{62}^\text{3} = \text{\np{238328}}$ to $\text{150}^\text{3} = \begin{table}[!t] \centering - \caption{Relative gain between the GMRES and the multisplitting algorithms wih for different configurations with 2 clusters, each one composed of 50 nodes.} + \caption{Relative gain of the multisplitting algorithm compared to GMRES for + different configurations with 2 clusters, each one composed of 50 nodes.} \label{tab.cluster.2x50} \begin{mytable}{5} @@ -656,10 +657,10 @@ Note that the program was run with the following parameters: After analyzing the outputs, generally, for the two clusters including one hundred hosts configuration (Tables~\ref{tab.cluster.2x50}), some combinations of parameters affecting the results have given a relative gain more than 2.5, showing the effectiveness of the -asynchronous performance compared to the synchronous mode. +asynchronous multiplsitting compared to GMRES with two distant clusters. With these settings, Table~\ref{tab.cluster.2x50} shows -that after a deterioration of inter cluster network with a bandwidth of \np[Mbit/s]{5} and a latency in order of one hundredth of millisecond and a processor power +that after setting the bandwidth of the inter cluster network to \np[Mbit/s]{5} and a latency in order of one hundredth of millisecond and a processor power of one GFlops, an efficiency of about \np[\%]{40} is obtained in asynchronous mode for a matrix size of 62 elements. It is noticed that the result remains stable even we vary the residual error precision from \np{E-5} to \np{E-9}. By @@ -706,17 +707,18 @@ of the cluster and network specifications permitting to save time in executing the algorithm in asynchronous mode. \end{enumerate} Our results have shown that in certain conditions, asynchronous mode is -speeder up to \np[\%]{40} than executing the algorithm in synchronous mode +speeder up to \np[\%]{40} comparing to the synchronous GMRES method which is not negligible for solving complex practical problems with more and more increasing size. - Several studies have already addressed the performance execution time of +Several studies have already addressed the performance execution time of this class of algorithm. The work presented in this paper has demonstrated an original solution to optimize the use of a simulation tool to run efficiently an iterative parallel algorithm in asynchronous mode in a grid architecture. -\LZK{Perspectives???} +For our futur works, we plan to extend our experimentations to larger scale platforms by increasing the number of computing cores and the number of clusters. +We will also have to increase the size of the input problem which will require the use of a more powerful simulation platform. At last, we expect to compare our simulation results to real execution results on real architectures in order to experimentally validate our study. \section*{Acknowledgment}