X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/GMRES2stage.git/blobdiff_plain/af93eecf8bd45d51b68e4c9ac79d9e2bf7100db4..a559d16ba3585ae8fb9457c67cf66851a5d463c8:/paper.tex diff --git a/paper.tex b/paper.tex index 2d34b8f..c8e503d 100644 --- a/paper.tex +++ b/paper.tex @@ -947,16 +947,16 @@ to read the codes available in the PETSc sources. Those problems have been chosen because they are scalable with many cores. In the following larger experiments are described on two large scale -architectures: Curie and Juqeen. Both these architectures are supercomputer -composed of 80,640 cores for Curie and 458,752 cores for Juqueen. Those machines -are respectively hosted by GENCI in France and Jülich Supercomputing Centre in -Germany. They belongs with other similar architectures of the PRACE initiative ( -Partnership for Advanced Computing in Europe) which aims at proposing high -performance supercomputing architecture to enhance research in Europe. The Curie -architecture is composed of Intel E5-2680 processors at 2.7 GHz with 2Gb memory -by core. The Juqueen architecture is composed of IBM PowerPC A2 at 1.6 GHz with -1Gb memory per core. Both those architecture are equiped with a dedicated high -speed network. +architectures: Curie and Juqueen. Both these architectures are supercomputer +respectively composed of 80,640 cores for Curie and 458,752 cores for +Juqueen. Those machines are respectively hosted by GENCI in France and Jülich +Supercomputing Centre in Germany. They belongs with other similar architectures +of the PRACE initiative (Partnership for Advanced Computing in Europe) which +aims at proposing high performance supercomputing architecture to enhance +research in Europe. The Curie architecture is composed of Intel E5-2680 +processors at 2.7 GHz with 2Gb memory by core. The Juqueen architecture is +composed of IBM PowerPC A2 at 1.6 GHz with 1Gb memory per core. Both those +architecture are equiped with a dedicated high speed network. In many situations, using preconditioners is essential in order to find the @@ -964,7 +964,7 @@ solution of a linear system. There are many preconditioners available in PETSc. For parallel applications all the preconditioners based on matrix factorization are not available. In our experiments, we have tested different kinds of preconditioners, however as it is not the subject of this paper, we will not -present results with many preconditioners. In practise, we have chosen to use a +present results with many preconditioners. In practice, we have chosen to use a multigrid (mg) and successive over-relaxation (sor). For more details on the preconditioner in PETSc please consult~\cite{petsc-web-page}. @@ -996,26 +996,29 @@ preconditioner in PETSc please consult~\cite{petsc-web-page}. Table~\ref{tab:03} shows the execution times and the number of iterations of example ex15 of PETSc on the Juqueen architecture. Different numbers of cores -are studied ranging from 2,048 up-to 16,383 with the two preconditioners {\it mg} and {\it sor}. For those experiments, the number of components (or unknowns of the -problems) per core is fixed to 25,000, also called weak scaling. This -number can seem relatively small. In fact, for some applications that need a lot -of memory, the number of components per processor requires sometimes to be -small. - - - -In Table~\ref{tab:03}, we can notice that TSIRM is always faster than FGMRES. The last -column shows the ratio between FGMRES and the best version of TSIRM according to -the minimization procedure: CGLS or LSQR. Even if we have computed the worst -case between CGLS and LSQR, it is clear that TSIRM is always faster than -FGMRES. For this example, the multigrid preconditioner is faster than SOR. The -gain between TSIRM and FGMRES is more or less similar for the two +are studied ranging from 2,048 up-to 16,383 with the two preconditioners {\it + mg} and {\it sor}. For those experiments, the number of components (or +unknowns of the problems) per core is fixed to 25,000, also called weak +scaling. This number can seem relatively small. In fact, for some applications +that need a lot of memory, the number of components per processor requires +sometimes to be small. Other parameters for this application are described in +the legend of this Table. + + + +In Table~\ref{tab:03}, we can notice that TSIRM is always faster than +FGMRES. The last column shows the ratio between FGMRES and the best version of +TSIRM according to the minimization procedure: CGLS or LSQR. Even if we have +computed the worst case between CGLS and LSQR, it is clear that TSIRM is always +faster than FGMRES. For this example, the multigrid preconditioner is faster +than SOR. The gain between TSIRM and FGMRES is more or less similar for the two preconditioners. Looking at the number of iterations to reach the convergence, it is obvious that TSIRM allows the reduction of the number of iterations. It should be noticed that for TSIRM, in those experiments, only the iterations of the Krylov solver are taken into account. Iterations of CGLS or LSQR were not -recorded but they are time-consuming. In general each $max\_iter_{kryl}*s$ which -corresponds to 30*12, there are $max\_iter_{ls}$ which corresponds to 15. +recorded but they are time-consuming. In general each $max\_iter_{kryl}*s$ +iterations which corresponds to 30*12, there are $max\_iter_{ls}$ iterations for +the least-squares method which corresponds to 15. \begin{figure}[htbp] \centering @@ -1068,10 +1071,10 @@ architecture are reported. For this application, we fixed $\alpha=0.6$. As it can be seen in that Table, the size of the problem has a strong influence on the number of iterations to reach the convergence. That is why we have preferred to change the threshold. If we set it to $1e-3$ as with the previous application, -only one iteration is necessray to reach the convergence. So Table~\ref{tab:04} -shows the results of differents executions with differents number of cores and -differents thresholds. As with the previous example, we can observe that TSIRM -is faster than FGMRES. The ratio greatly depends on the number of iterations for +only one iteration is necessary to reach the convergence. So Table~\ref{tab:04} +shows the results of different executions with different number of cores and +different thresholds. As with the previous example, we can observe that TSIRM is +faster than FGMRES. The ratio greatly depends on the number of iterations for FMGRES to reach the threshold. The greater the number of iterations to reach the convergence is, the better the ratio between our algorithm and FMGRES is. This experiment is also a weak scaling with approximately $25,000$ components per @@ -1083,19 +1086,20 @@ Table~\ref{tab:05} show a strong scaling experiment with the exemple ex54 on the Curie architecture. So in this case, the number of unknownws is fixed to $204,919,225$ and the number of cores ranges from $512$ to $8192$ with the power of two. The threshold is fixed to $5e-5$ and only the $mg$ preconditioner has -been tested. Here again we can see that TSIRM is faster that FGMRES. Efficiecy -of each algorithms is reported. It can be noticed that FGMRES is more efficient -than TSIRM except with $8,192$ cores and that its efficiency is greater that one -whereas the efficiency of TSIRM is lower than one. Nevertheless, the ratio of -TSIRM with any version of the least-squares method is always faster. With -$8,192$ cores when the number of iterations is far more important for FGMRES, we -can see that it is only slightly more important for TSIRM. +been tested. Here again we can see that TSIRM is faster that FGMRES. Efficiency +of each algorithm is reported. It can be noticed that the efficiency of FGMRES +is better than the TSIRM one except with $8,192$ cores and that its efficiency +is greater that one whereas the efficiency of TSIRM is lower than +one. Nevertheless, the ratio of TSIRM with any version of the least-squares +method is always faster. With $8,192$ cores when the number of iterations is +far more important for FGMRES, we can see that it is only slightly more +important for TSIRM. In Figure~\ref{fig:02} we report the number of iterations per second for -experiments reported in Table~\ref{tab:05}. This Figure highlights that the -number of iterations per seconds is more of less the same for FGMRES and TSIRM +experiments reported in Table~\ref{tab:05}. This Figure highlights that the +number of iterations per second is more of less the same for FGMRES and TSIRM with a little advantage for FGMRES. It can be explained by the fact that, as we -have previously explained, that the iterations of the least-sqaure steps are not +have previously explained, that the iterations of the least-squares steps are not taken into account with TSIRM. \begin{table*}[htbp] @@ -1115,7 +1119,7 @@ taken into account with TSIRM. \hline \end{tabular} -\caption{Comparison of FGMRES and TSIRM with FGMRES for ex54 of Petsc (both with the MG preconditioner) with 204,919,225 components on Curie with different number of cores ($\epsilon_{tsirm}=5e-5$, $max\_iter_{kryl}=30$, $s=12$, $max\_iter_{ls}=15$, $\epsilon_{ls}=1e-40$), time is expressed in seconds.} +\caption{Comparison of FGMRES and TSIRM for ex54 of PETSc (both with the MG preconditioner) with 204,919,225 components on Curie with different number of cores ($\epsilon_{tsirm}=5e-5$, $max\_iter_{kryl}=30$, $s=12$, $max\_iter_{ls}=15$, $\epsilon_{ls}=1e-40$), time is expressed in seconds.} \label{tab:05} \end{center} \end{table*} @@ -1130,16 +1134,16 @@ taken into account with TSIRM. Concerning the experiments some other remarks are interesting. \begin{itemize} -\item We can tested other examples of PETSc (ex29, ex45, ex49). For all these +\item We have tested other examples of PETSc (ex29, ex45, ex49). For all these examples, we also obtained similar gain between GMRES and TSIRM but those examples are not scalable with many cores. In general, we had some problems with more than $4,096$ cores. -\item We have tested many iterative solvers available in PETSc. In fast, it is +\item We have tested many iterative solvers available in PETSc. In fact, it is possible to use most of them with TSIRM. From our point of view, the condition to use a solver inside TSIRM is that the solver must have a restart - feature. More precisely, the solver must support to be stoped and restarted + feature. More precisely, the solver must support to be stopped and restarted without decrease its converge. That is why with GMRES we stop it when it is - naturraly restarted (i.e. with $m$ the restart parameter). The Conjugate + naturally restarted (i.e. with $m$ the restart parameter). The Conjugate Gradient (CG) and all its variants do not have ``restarted'' version in PETSc, so they are not efficient. They will converge with TSIRM but not quickly because if we compare a normal CG with a CG for which we stop it each 16