\usepackage{amsmath}
\usepackage{courier}
\usepackage{graphicx}
+\usepackage{url}
\usepackage[ruled,lined]{algorithm2e}
\newcommand{\abs}[1]{\lvert#1\rvert} % \abs{x} -> |x|
}
\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}
+ raphael.couturier@femto-st.fr,
+ arnaud.giersch@femto-st.fr}
}
\maketitle
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
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.
-\FIXME{What about Section~\ref{Other}?}
+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.
\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;
\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 \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}.
\FIXME{ajouter des détails sur la gestion de la charge virtuelle ?}
\subsection{Experimental contexts}
\label{Contexts}
-\paragraph{Configurations}
+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[\textbf{platforms}] homogeneous (cluster); heterogeneous (subset
- of Grid5000)
-\item[\textbf{platform size}] platforms with 16, 64, 256, and 1024 nodes
-\item[\textbf{topologies}] line; torus; hypercube
-\item[\textbf{initial load distribution}] initially on a only node;
- initially on all nodes
-\item[\textbf{comp/comm ratio}] $10/1$, $1/1$, $1/10$
+\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{Configurations}
+
+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 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 only comes from the network topology. The processor speeds, and
+network bandwidths were normalized since our algorithms currently are not aware
+of such heterogeneity. We arbitrarily chose to fix the processor speed to
+1~GFlop/s, and the network bandwidth to 125~MB/s, with a latency of 50~$\mu$s,
+except for the links between geographically distant sites, where the network
+bandwidth was fixed to 2.25~GB/s, with a latency of 500~$\mu$s.
+
+Then we derived each sort of platform with four different number of computing
+nodes: 16, 64, 256, and 1024 nodes.
+
+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.
+
+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}
-\paragraph{Algorithms}
+To summarize the various configurations, we have:
\begin{description}
-\item[\textbf{strategies}] makhoul; besteffort with $k\in \{1,2,4\}$
-\item[\textbf{variants}] with, and without virtual load (bookkeeping)
-\item[\textbf{domain}] real load, and integer load
+\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}
\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}
%%% 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
