X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/loba-papers.git/blobdiff_plain/c830f3e358627198e6ce11ebd077195ebe82eccc..99c4629e78a3a929c5ba423fc7d6f11cb495e6f1:/supercomp11/supercomp11.tex?ds=inline diff --git a/supercomp11/supercomp11.tex b/supercomp11/supercomp11.tex index 472a724..2f2dd31 100644 --- a/supercomp11/supercomp11.tex +++ b/supercomp11/supercomp11.tex @@ -5,6 +5,7 @@ \usepackage{amsmath} \usepackage{courier} \usepackage{graphicx} +\usepackage{url} \usepackage[ruled,lined]{algorithm2e} \newcommand{\abs}[1]{\lvert#1\rvert} % \abs{x} -> |x| @@ -13,6 +14,9 @@ \begin{tabular}[t]{@{}l@{:~}l@{}}}{% \end{tabular}} +\newcommand{\FIXME}[1]{% + \textbf{$\triangleright$\marginpar{\textbf{[FIXME]}}~#1}} + \newcommand{\VAR}[1]{\textit{#1}} \begin{document} @@ -21,21 +25,16 @@ for asynchronous iterative load balancing} \author{Raphaël Couturier \and - Arnaud Giersch \and - Abderrahmane Sider + Arnaud Giersch } \institute{R. Couturier \and A. Giersch \at - LIFC, University of Franche-Comté, Belfort, France \\ + FEMTO-ST, University of Franche-Comté, Belfort, France \\ % Tel.: +123-45-678910\\ % Fax: +123-45-678910\\ \email{% - raphael.couturier@univ-fcomte.fr, - arnaud.giersch@univ-fcomte.fr} - \and - A. Sider \at - University of Béjaïa, Béjaïa, Algeria \\ - \email{ar.sider@univ-bejaia.dz} + raphael.couturier@femto-st.fr, + arnaud.giersch@femto-st.fr} } \maketitle @@ -86,7 +85,7 @@ been extended by many authors. For example, Cortés et al., with DASUD~\cite{cortes+ripoll+cedo+al.2002.asynchronous}, propose a version working with integer load. This work was later generalized by the same authors in \cite{cedo+cortes+ripoll+al.2007.convergence}. -{\bf Rajouter des choses ici}. +\FIXME{Rajouter des choses ici.} Although the Bertsekas and Tsitsiklis' algorithm describes the condition to ensure the convergence, there is no indication or strategy to really implement @@ -98,7 +97,7 @@ ensuring that all the nodes concerned by the load balancing phase have the same amount of load. Moreover, when real asynchronous applications are considered, using asynchronous load balancing algorithms can reduce the execution times. Most of the times, it is simpler to distinguish load information messages -from data migration messages. Formers ones allows a node to inform its +from data migration messages. Former ones allows a node to inform its neighbors of its current load. These messages are very small, they can be sent quite often. For example, if an computing iteration takes a significant times (ranging from seconds to minutes), it is possible to send a new load information @@ -122,15 +121,15 @@ order to send a message, a latency delays the sending and according to the network performance and the message size, the time of the reception of the message also varies. -In the following of this paper, Section~\ref{BT algo} describes the Bertsekas -and Tsitsiklis' asynchronous load balancing algorithm. Moreover, we present a -possible problem in the convergence conditions. Section~\ref{Best-effort} -presents the best effort strategy which provides an efficient way to reduce the -execution times. In Section~\ref{Virtual load}, the virtual load mechanism is -proposed. Simulations allowed to show that both our approaches are valid using a -quite realistic model detailed in Section~\ref{Simulations}. Finally we give a -conclusion and some perspectives to this work. - +In the following of this paper, Section~\ref{BT algo} describes the Bertsekas +and Tsitsiklis' asynchronous load balancing algorithm. Moreover, we present a +possible problem in the convergence conditions. Section~\ref{Best-effort} +presents the best effort strategy which provides an efficient way to reduce the +execution times. This strategy will be compared with other ones, presented in +Section~\ref{Other}. In Section~\ref{Virtual load}, the virtual load mechanism +is proposed. Simulations allowed to show that both our approaches are valid +using a quite realistic model detailed in Section~\ref{Simulations}. Finally we +give a conclusion and some perspectives to this work. @@ -187,16 +186,25 @@ $3$. If it sends load to processor $1$ it will not satisfy condition $x_3^2(t)$. So we consider that the \emph{ping-pong} condition is probably to strong. Currently, we did not try to make another convergence proof without this condition or with a weaker condition. - +% +\FIXME{Develop: We have the feeling that such a weaker condition + exists, because (it's not a proof, but) we have never seen any + scenario that is not leading to convergence, even with LB-strategies + that are not fulfilling these two conditions.} \section{Best effort strategy} \label{Best-effort} -In this section we describe a new load-balancing strategy that we call -\emph{best effort}. The general idea behind this strategy is that each -processor, that detects it has more load than some of its neighbors, -sends some load to the most of its less loaded neighbors, doing its -best to reach the equilibrium between those neighbors and himself. +In this section we describe a new load-balancing strategy that we call +\emph{best effort}. First, we explain the general idea behind this strategy, +and then we describe some variants of this basic strategy. + +\subsection{Basic strategy} + +The general idea behind the \emph{best effort} strategy is that each processor, +that detects it has more load than some of its neighbors, sends some load to the +most of its less loaded neighbors, doing its best to reach the equilibrium +between those neighbors and himself. More precisely, when a processor $i$ is in its load-balancing phase, he proceeds as following. @@ -243,24 +251,44 @@ he proceeds as following. \end{equation*} \end{enumerate} +\subsection{Leveling the amount to send} + +With the aforementioned basic strategy, each node does its best to reach the +equilibrium with its neighbors. Since each node may be taking the same kind of +decision at the same moment, there is the risk that a node receives load from +several of its neighbors, and then is temporary going off the equilibrium state. +This is particularly true with strongly connected applications. + +In order to reduce this effect, we add the ability to level the amount to send. +The idea, here, is to make smaller steps toward the equilibrium, such as a +potentially wrong decision has a lower impact. + +Concretely, once $s_{ij}$ has been evaluated as before, it is simply divided by +some configurable factor. That's what we named the ``parameter $k$'' in +Section~\ref{Results}. The amount of data to send is then $s_{ij}(t) = (\bar{x} +- x^i_j(t))/k$. +\FIXME{check the name ($k$)} + \section{Other strategies} \label{Other} -\textbf{Question} faut-il décrire les stratégies makhoul et simple ? +\FIXME{Réécrire en anglais.} -\paragraph{simple} Tentative de respecter simplement les conditions de Bertsekas. -Parmi les voisins moins chargés que soi, on sélectionne : -\begin{itemize} -\item un des moins chargés (vmin) ; -\item un des plus chargés (vmax), -\end{itemize} -puis on équilibre avec vmin en s'assurant que notre charge reste -toujours supérieure à celle de vmin et à celle de vmax. +% \FIXME{faut-il décrire les stratégies makhoul et simple ?} + +% \paragraph{simple} Tentative de respecter simplement les conditions de Bertsekas. +% Parmi les voisins moins chargés que soi, on sélectionne : +% \begin{itemize} +% \item un des moins chargés (vmin) ; +% \item un des plus chargés (vmax), +% \end{itemize} +% puis on équilibre avec vmin en s'assurant que notre charge reste +% toujours supérieure à celle de vmin et à celle de vmax. -On envoie donc (avec "self" pour soi-même) : -\[ - \min\left(\frac{load(self) - load(vmin)}{2}, load(self) - load(vmax)\right) -\] +% On envoie donc (avec "self" pour soi-même) : +% \[ +% \min\left(\frac{load(self) - load(vmin)}{2}, load(self) - load(vmax)\right) +% \] \paragraph{makhoul} Ordonne les voisins du moins chargé au plus chargé puis calcule les différences de charge entre soi-même et chacun des @@ -298,7 +326,9 @@ balancing message. Doing this, we can expect a faster convergence since nodes have a faster information of the load they will receive, so they can take in into account. -\textbf{Question} Est ce qu'on donne l'algo avec virtual load? +\FIXME{Est ce qu'on donne l'algo avec virtual load?} + +\FIXME{describe integer mode} \section{Simulations} \label{Simulations} @@ -412,7 +442,8 @@ example, when the current load is near zero). \paragraph{Load-balancing thread} The load-balancing thread is in charge of running the load-balancing algorithm, and exchange the -control messages. It iteratively runs the following operations: +control messages. As shown in Algorithm~\ref{algo.lb}, it iteratively +runs the following operations: \begin{itemize} \item get the control messages that were received from the neighbors; \item run the load-balancing algorithm; @@ -442,21 +473,164 @@ control messages. It iteratively runs the following operations: \paragraph{} For the sake of simplicity, a few details were voluntary omitted from these descriptions. For an exhaustive presentation, we refer to the -actual code that was used for the experiments, and which is -available at \textbf{FIXME URL}. +actual source code that was used for the experiments% +\footnote{As mentioned before, our simulator relies on the SimGrid + framework~\cite{casanova+legrand+quinson.2008.simgrid}. For the + experiments, we used a pre-release of SimGrid 3.7 (Git commit + 67d62fca5bdee96f590c942b50021cdde5ce0c07, available from + \url{https://gforge.inria.fr/scm/?group_id=12})}, and which is +available at +\url{http://info.iut-bm.univ-fcomte.fr/staff/giersch/software/loba.tar.gz}. -\textbf{FIXME: ajouter des détails sur la gestion de la charge virtuelle ?} +\FIXME{ajouter des détails sur la gestion de la charge virtuelle ?} \subsection{Experimental contexts} \label{Contexts} -\textbf{FIXME once the experimentation is done!} +In order to assess the performances of our algorithms, we ran our +simulator with various parameters, and extracted several metrics, that +we will describe in this section. + +\paragraph{Load balancing strategies} + +Several load balancing strategies were compared. We ran the experiments with +the \emph{Best effort}, and with the \emph{Makhoul} strategies. \emph{Best + effort} was tested with parameter $k = 1$, $k = 2$, and $k = 4$. Secondly, +each strategy was run in its two variants: with, and without the management of +\emph{virtual load}. Finally, we tested each configuration with \emph{real}, +and with \emph{integer} load. + +To summarize the different load balancing strategies, we have: \begin{description} -\item[platforms] homogeneous ; heterogeneous generated with the SIMULACRUM tool~\cite{QUINSON:2010:INRIA-00502839:1} -\item[topologies] -\item[algorithms] -\item[etc.] +\item[\textbf{strategies:}] \emph{Makhoul}, or \emph{Best effort} with $k\in + \{1,2,4\}$ +\item[\textbf{variants:}] with, or without virtual load +\item[\textbf{domain:}] real load, or integer load \end{description} +% +This gives us as many as $4\times 2\times 2 = 16$ different strategies. + +\paragraph{End of the simulation} + +The simulations were run until the load was nearly balanced among the +participating nodes. More precisely the simulation stops when each node holds +an amount of load at less than 1\% of the load average, during an arbitrary +number of computing iterations (2000 in our case). + +Note that this convergence detection was implemented in a centralized manner. +This is easy to do within the simulator, but it's obviously not realistic. In a +real application we would have chosen a decentralized convergence detection +algorithm, like the one described in \cite{10.1109/TPDS.2005.2}. + +\paragraph{Platforms} + +In order to show the behavior of the different strategies in different +settings, we simulated the executions on two sorts of platforms. These two +sorts of platforms differ by their underlaid network topology. On the one hand, +we have homogeneous platforms, modeled as a cluster. On the other hand, we have +heterogeneous platforms, modeled as the interconnection of a number of clusters. + +The clusters were modeled by a fixed number of computing nodes interconnected +through a backbone link. Each computing node has a computing power of +1~GFlop/s, and is connected to the backbone by a network link whose bandwidth is +of 125~MB/s, with a latency of 50~$\mu$s. The backbone has a network bandwidth +of 2.25~GB/s, with a latency of 500~$\mu$s. + +The heterogeneous platform descriptions were created by taking a subset of the +Grid'5000 infrastructure\footnote{Grid'5000 is a French large scale experimental + Grid (see \url{https://www.grid5000.fr/}).}, as described in the platform file +\texttt{g5k.xml} distributed with SimGrid. Note that the heterogeneity of the +platform here only comes from the network topology. Indeed, since our +algorithms currently do not handle heterogeneous computing resources, the +processor speeds were normalized, and we arbitrarily chose to fix them to +1~GFlop/s. + +Then we derived each sort of platform with four different number of computing +nodes: 16, 64, 256, and 1024 nodes. + +\paragraph{Configurations} + +The distributed processes of the application were then logically organized along +three possible topologies: a line, a torus or an hypercube. We ran tests where +the total load was initially on an only node (at one end for the line topology), +and other tests where the load was initially randomly distributed across all the +participating nodes. The total amount of load was fixed to a number of load +units equal to 1000 times the number of node. The average load is then of 1000 +load units. + +For each of the preceding configuration, we finally had to choose the +computation and communication costs of a load unit. We chose them, such as to +have three different computation over communication cost ratios, and hence model +three different kinds of applications: +\begin{itemize} +\item mainly communicating, with a computation/communication cost ratio of $1/10$; +\item mainly computing, with a computation/communication cost ratio of $10/1$ ; +\item balanced, with a computation/communication cost ratio of $1/1$. +\end{itemize} + +To summarize the various configurations, we have: +\begin{description} +\item[\textbf{platforms:}] homogeneous (cluster), or heterogeneous (subset of + Grid'5000) +\item[\textbf{platform sizes:}] platforms with 16, 64, 256, or 1024 nodes +\item[\textbf{process topologies:}] line, torus, or hypercube +\item[\textbf{initial load distribution:}] initially on a only node, or + initially randomly distributed over all nodes +\item[\textbf{computation/communication ratio:}] $10/1$, $1/1$, or $1/10$ +\end{description} +% +This gives us as many as $2\times 4\times 3\times 2\times 3 = 144$ different +configurations. +% +Combined with the various load balancing strategies, we had $16\times 144 = +2304$ distinct settings to evaluate. In fact, as it will be shown later, we +didn't run all the strategies, nor all the configurations for the bigger +platforms with 1024 nodes, since to simulations would have run for a too long +time. + +Anyway, all these the experiments represent more than 240 hours of computing +time. + +\paragraph{Metrics} + +In order to evaluate and compare the different load balancing strategies we had +to define several metrics. Our goal, when choosing these metrics, was to have +something tending to a constant value, i.e. to have a measure which is not +changing anymore once the convergence state is reached. Moreover, we wanted to +have some normalized value, in order to be able to compare them across different +settings. + +With these constraints in mind, we defined the following metrics: +% +\begin{description} +\item[\textbf{average idle time:}] that's the total time spent, when the nodes + don't hold any share of load, and thus have nothing to compute. This total + time is divided by the number of participating nodes, such as to have a number + that can be compared between simulations of different sizes. + + This metric is expected to give an idea of the ability of the strategy to + diffuse the load quickly. A smaller value is better. + +\item[\textbf{average convergence date:}] that's the average of the dates when + all nodes reached the convergence state. The dates are measured as a number + of (simulated) seconds since the beginning of the simulation. + +\item[\textbf{maximum convergence date:}] that's the date when the last node + reached the convergence state. + + These two dates give an idea of the time needed by the strategy to reach the + equilibrium state. A smaller value is better. + +\item[\textbf{data transfer amount:}] that's the sum of the amount of all data + transfers during the simulation. This sum is then normalized by dividing it + by the total amount of data present in the system. + + This metric is expected to give an idea of the efficiency of the strategy in + terms of data movements, i.e. its ability to reach the equilibrium with fewer + transfers. Again, a smaller value is better. + +\end{description} + \subsection{Validation of our approaches} \label{Results} @@ -491,6 +665,10 @@ Taille : 10 100 très gros \section{Conclusion and perspectives} +\begin{acknowledgements} + Computations have been performed on the supercomputer facilities of + the Mésocentre de calcul de Franche-Comté. +\end{acknowledgements} \bibliographystyle{spmpsci} \bibliography{biblio} @@ -500,9 +678,10 @@ Taille : 10 100 très gros %%% Local Variables: %%% mode: latex %%% TeX-master: t +%%% fill-column: 80 %%% ispell-local-dictionary: "american" %%% End: % LocalWords: Raphaël Couturier Arnaud Giersch Abderrahmane Sider Franche ij % LocalWords: Bertsekas Tsitsiklis SimGrid DASUD Comté Béjaïa asynchronism ji -% LocalWords: ik isend irecv Cortés et al chan ctrl fifo +% LocalWords: ik isend irecv Cortés et al chan ctrl fifo Makhoul GFlop xml