+Before looking at the different variations, we will first show that the plain
+\besteffort{} strategy is valuable, and may be as good as the \makhoul{}
+strategy. On Figures~\ref{fig.results1} and~\ref{fig.resultsN},
+these strategies are respectively labeled ``b'' and ``a''.
+
+We can see that the relative performance of these strategies is mainly
+influenced by the application topology. It is for the line topology that the
+difference is the more important. In this case, the \besteffort{} strategy is
+nearly faster than the \makhoul{} strategy. This can be explained by the
+fact that the \besteffort{} strategy tries to distribute the load fairly between
+all the nodes and with the line topology, it is easy to load balance the load
+fairly.
+
+On the contrary, for the hypercube topology, the \besteffort{} strategy performs
+worse than the \makhoul{} strategy. In this case, the \makhoul{} strategy which
+tries to give more load to few neighbors reaches the equilibrium faster.
+
+For the torus topology, for which the number of links is between the line and
+the hypercube, the \makhoul{} strategy is slightly better but the difference is
+more nuanced when the initial load is only on one node. The only case where the
+\makhoul{} strategy is really faster than the \besteffort{} strategy is with the
+random initial distribution when the communication are slow.
+
+Globally the number of interconnection is very important. The more
+the interconnection links are, the faster the \makhoul{} strategy is because
+it distributes quickly significant amount of load, even if this is unfair, between
+all the neighbors. In opposition, the \besteffort{} strategy distributes the
+load fairly so this strategy is better for low connected strategy.
+
+
+
+
+
+\subsubsection{Virtual load}
+
+The influence of virtual load is most of the time really significant compared to
+the same configuration without it. Sometimes it has no effect but, based on our observations, it has never a negative effect on the load balancing we tested.
+
+On Figure~\ref{fig.results1}, when the load is initially on one node, it can be
+noticed that the average idle times are generally longer with the virtual load
+than without it. This can be explained by the fact that, with virtual load,
+processors will exchange all the load they need to exchange as soon as the
+virtual load has been balanced between all the processors. So consequently they
+cannot compute at the beginning. This is especially noticeable when the
+communication are slow (on the left part of Figure ~\ref{fig.results1}.
+
+On Figure \ref{fig.resultsN} when the load to balance is initially randomly distributed over all nodes, we can see that the effect of virtual load is not significant for the line. For the torus with the mainly communicating case (on the left of the figure), the effect of the virtual load is very significant. For the hypercube, in any case, the effect of the virtual load is visible. It is more visible when communications have a more important role (i.e. with the mainly communicating case).
+
+
+%Dans ce cas légère amélioration de la cvg. max. Temps moyen de cvg. amélioré,
+%mais plus de temps passé en idle, surtout quand les comms coutent cher.
+
+%\subsubsection{The \besteffort{} strategy with an initial random load
+% distribution, and larger platforms}
+
+%In
+%Mêmes conclusions pour line et hcube.
+%Sur tore, BE se fait exploser quand les comms coutent cher.
+
+%\FIXME{virer les 1024 ?}
+
+%\subsubsection{With the virtual load extension with an initial random load
+% distribution}
+
+%Soit c'est équivalent, soit on gagne -> surtout quand les comms coutent cher et
+%qu'il y a beaucoup de voisins.
