X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/loba-papers.git/blobdiff_plain/e98f1ccead5d206a6da91407b7298efbf0d828d7..77dfff6971a1d64b3274379ad340410840d24980:/supercomp11/supercomp11.tex?ds=inline

diff --git a/supercomp11/supercomp11.tex b/supercomp11/supercomp11.tex
index 4cc971b..b0d23b0 100644
--- a/supercomp11/supercomp11.tex
+++ b/supercomp11/supercomp11.tex
@@ -97,17 +97,17 @@ message at each  neighbor at each iteration. Latter  messages contains data that
 migrates from one node to another one. Depending on the application, it may have
 sense or not  that nodes try to balance  a part of their load  at each computing
 iteration. But the time to transfer a load message from a node to another one is
-often much nore longer that to  time to transfer a load information message. So,
+often much more longer that to  time to transfer a load information message. So,
 when a node receives the information  that later it will receive a data message,
 it can take this information into account  and it can consider that its new load
 is larger.   Consequently, it can  send a part  of it real  load to some  of its
-neighbors if required. We call this trick the \emph{virtual load} mecanism.
+neighbors if required. We call this trick the \emph{virtual load} mechanism.
 
 
 
 So, in  this work, we propose a  new strategy for improving  the distribution of
 the  load  and  a  simple  but  efficient trick  that  also  improves  the  load
-balacing. Moreover, we have conducted  many simulations with simgrid in order to
+balancing. Moreover, we have conducted  many simulations with SimGrid in order to
 validate our improvements are really efficient. Our simulations consider that in
 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
@@ -117,7 +117,7 @@ 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  mecanism is
+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.
@@ -129,11 +129,11 @@ conclusion and some perspectives to this work.
 \label{BT algo}
 
 In  order  prove  the  convergence  of  asynchronous  iterative  load  balancing
-Bertesekas         and        Tsitsiklis         proposed         a        model
+Bertsekas         and        Tsitsiklis         proposed         a        model
 in~\cite{bertsekas+tsitsiklis.1997.parallel}.   Here we  recall  some notations.
 Consider  that  $N={1,...,n}$  processors   are  connected  through  a  network.
 Communication links  are represented by  a connected undirected  graph $G=(N,V)$
-where $V$ is the set of links connecting differents processors. In this work, we
+where $V$ is the set of links connecting different processors. In this work, we
 consider that  processors are  homogeneous for sake  of simplicity. It  is quite
 easy to tackle the  heterogeneous case~\cite{ElsMonPre02}. Load of processor $i$
 at  time $t$  is  represented  by $x_i(t)\geq  0$.   Let $V(i)$  be  the set  of
@@ -144,7 +144,7 @@ consider that the load is described by a continuous variable.
 
 When a processor  send a part of its  load to one or some of  its neighbors, the
 transfer takes time to be completed.  Let $s_{ij}(t)$ be the amount of load that
-processor $i$ has transfered to processor $j$ at time $t$ and let $r_{ij}(t)$ be the
+processor $i$ has transferred to processor $j$ at time $t$ and let $r_{ij}(t)$ be the
 amount of  load received by processor $j$  from processor $i$ at  time $t$. Then
 the amount of load of processor $i$ at time $t+1$ is given by:
 \begin{equation}
@@ -159,13 +159,13 @@ called the \emph{ping-pong} condition which specifies that:
 x_i(t)-\sum _{k\in V(i)} s_{ik}(t) \geq x_j^i(t)+s_{ij}(t)
 \end{equation}
 for any  processor $i$ and any  $j \in V(i)$ such  that $x_i(t)>x_j^i(t)$.  This
-condition aims  at avoiding a processor  to send a  part of its load  and beeing
+condition aims  at avoiding a processor  to send a  part of its load  and being
 less loaded after that.
 
 Nevertheless,  we  think that  this  condition may  lead  to  deadlocks in  some
 cases. For example, if we consider  only three processors and that processor $1$
 is linked to processor $2$ which is  also linked to processor $3$ (i.e. a simple
-chain wich 3 processors). Now consider we have the following values at time $t$:
+chain which 3 processors). Now consider we have the following values at time $t$:
 \begin{eqnarray*}
 x_1(t)=10   \\
 x_2(t)=100   \\
@@ -270,69 +270,69 @@ C'est l'algorithme~2 dans~\cite{bahi+giersch+makhoul.2008.scalable}.
 
 In order to test and validate our approaches, we wrote a simulator
 using the SimGrid
-framework~\cite{casanova+legrand+quinson.2008.simgrid}.  The process
-model is detailed in the next section (\ref{Sim model}), then the
-results of the simulations are presented in section~\ref{Results}.
+framework~\cite{casanova+legrand+quinson.2008.simgrid}.  This
+simulator, which consists of about 2,700 lines of C++, allows to run
+the different load-balancing strategies under various parameters, such
+as the initial distribution of load, the interconnection topology, the
+characteristics of the running platform, etc.  Then several metrics
+are issued that permit to compare the strategies.
+
+The simulation model is detailed in the next section (\ref{Sim
+  model}), then the results of the simulations are presented in
+section~\ref{Results}.
 
 \subsection{Simulation model}
 \label{Sim model}
 
-\begin{verbatim}
-Communications
-==============
-
-There are two receiving channels per host: control for information
-messages, and data for load transfers.
-
-Process model
-=============
-
-Each process is made of 3 threads: a receiver thread, a computing
-thread, and a load-balancer thread.
-
-* Receiver thread
-  ---------------
-
-    Loop
-    | wait for a message to come, either on data channel, or on ctrl channel
-    | push received message in a buffer of received messages
-    | -> ctrl messages on the one side
-    | -> data messages on the other side
-    +-
-
-   The loop terminates when a "finalize" message is received on each
-   channel.
-
-* Computing thread
-  ----------------
-
-    Loop
-    | if we received some real load, get it (data messages)
-    | if there is some real load to send, send it
-    | if we own some load, simulate some computing on it
-    | sleep a bit if we are looping too fast
-    +-
-    send CLOSE on data for all neighbors
-    wait for CLOSE on data from all neighbors
-
-  The loop terminates when process::still_running() returns false.
-  (read the source for full details...)
-
-* Load-balancing thread
-  ---------------------
-
-    Loop
-    | call load-balancing algorithm
-    | send ctrl messages
-    | sleep (min_lb_iter_duration)
-    | receive ctrl messages
-    +-
-    send CLOSE on ctrl for all neighbors
-    wait for CLOSE on ctrl from all neighbors
+In the simulation model the processors exchange messages which are of
+two kinds.  First, there are \emph{control messages} which only carry
+information that is exchanged between the processors, such as the
+current load, or the virtual load transfers if this option is
+selected.  These messages are rather small, and their size is
+constant.  Then, there are \emph{data messages} that carry the real
+load transferred between the processors.  The size of a data message
+is a function of the amount of load that it carries, and it can be
+pretty large.  In order to receive the messages, each processor has
+two receiving channels, one for each kind of messages.  Finally, when
+a message is sent or received, this is done by using the non-blocking
+primitives of SimGrid\footnote{That are \texttt{MSG\_task\_isend()},
+  and \texttt{MSG\_task\_irecv()}.}.
+
+During the simulation, each processor concurrently runs three threads:
+a \emph{receiving thread}, a \emph{computing thread}, and a
+\emph{load-balancing thread}, which we will briefly describe now.
+
+\paragraph{Receiving thread} The receiving thread is in charge of
+waiting for messages to come, either on the control channel, or on the
+data channel.  When a message is received, it is pushed in a buffer of
+received message, to be later consumed by one of the other threads.
+There are two such buffers, one for the control messages, and one for
+the data messages.  The buffers are implemented with a lock-free FIFO
+\cite{sutter.2008.writing} to avoid contention between the threads.
+
+\paragraph{Computing thread} The computing thread is in charge of the
+real load management.  It iteratively runs the following operations:
+\begin{itemize}
+\item if some load was received from the neighbors, get it;
+\item if there is some load to send to the neighbors, send it;
+\item run some computation, whose duration is function of the current
+  load of the processor.
+\end{itemize}
+Practically, after the computation, the computing thread waits for a
+small amount of time if the iterations are looping too fast (for
+example, when the current load is zero).
 
-  The loop terminates when process::still_running() returns false.
-  (read the source for full details...)
-\end{verbatim}
+\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:
+\begin{itemize}
+\item get the control messages that were received from the neighbors;
+\item run the load-balancing algorithm;
+\item send control messages to the neighbors, to inform them of the
+  processor's current load, and possibly of virtual load transfers;
+\item wait a minimum (configurable) amount of time, to avoid to
+  iterate too fast.
+\end{itemize}
 
 \subsection{Validation of our approaches}
 \label{Results}
@@ -379,5 +379,6 @@ Taille : 10 100 très gros
 %%% ispell-local-dictionary: "american"
 %%% End:
 
-% LocalWords:  Raphaël Couturier Arnaud Giersch Abderrahmane Sider
-% LocalWords:  Bertsekas Tsitsiklis SimGrid DASUD
+% 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