Évaluation

État initial : Le système est composé de 4 ressources. Un compteur est associé à chaque res-source.

Étape 1 : Le site s₁ demande les

ressources res1 et res4.

Étape 2 : À chaque consultation de compteur, la valeur du comp-teur est renvoyée au demandeur puis incrémentée. Le vecteur est complété à chaque valeur reçue.

Étape 3 : Le site s₁ demande

in-dépendamment chaque ressource voulue en indiquant le vecteur.

Figure 7.2 – Exemple d’exécution d’obtention des compteurs

les cas d’égalité seront peu probables. L’utilisation de l’identifiant du site ne posera donc pas de problème d’équité.

7.4 Évaluation

Dans cette section , nous présentons une évaluation de performances de notre algo-rithme que nous comparons avec deux algoalgo-rithmes de l’état de l’art. Nous nous intéressons à deux métriques : le taux d’utilisation des ressources et le temps d’attente pour obtenir la section critique.

7.4.1 Protocole d’évaluation

Algorithmes considérés

Cette section d’évaluation de performances compare :

• un algorithme incrémental fixant un ordre prédéfini d’accès aux ressources et utili-sant M instances d’algorithme de Naimi-Tréhel avec files locales [NT87b] (cf. section 2.5.2)

106 Chapitre 7. Verrouiller efficacement les ressources sans connaissance préalable des conflits • l’implémentation distribuée de notre mécanisme basé sur les compteurs (voir annexe

A)

Notre algorithme nécessitant la définition de la fonction A, nous avons choisi de comparer deux politiques :

• Politique équitable : La première politique calcule la moyenne des compteurs non nuls : le résultat donne donc un compteur moyen par ressource demandée. • Politique favorisant les petites requêtes Une solution naïve pour améliorer

le taux d’utilisation serait d’avoir une définition de A qui favoriserait les requêtes requérant peu de ressources. En effet, ces requêtes ont moins de chances d’être en conflit avec une autre du fait de leurs petites tailles. Dans cette politique, A est égale à la moyenne de l’ensemble des valeurs du vecteur de la requête. Puisque les ressources non requises ont une valeur nulle dans le vecteur, les petites requêtes demandant peu de ressources en seront privilégiées.

Dans les deux cas, la famine est impossible car les compteurs augmentent à chaque nouvelle requête impliquant que la valeur minimum de A augmentera également à chaque nouvelle requête. La propriété de vivacité est ainsi toujours respectée. L’avantage du mécanisme de la fonction A réside dans le fait que la famine est évitée seulement grâce à un calcul qui n’implique aucun surcoût en communication.

Plate-forme et paramètres d’expérimentation

Les expériences ont été menées sur un cluster de 32 machines (Grid5000 Lyon) avec un processus par machine pour éviter les effets de bords de contention sur les cartes réseau. Chaque machine a deux processeurs Xeon 2.4GHz, 32 GB de mémoire RAM et fonctionne sous Linux 2.6. Les machines sont reliées par un switch Ethernet 10 Gbit/s. Les algorithmes ont été implémentées en C++ et OpenMPI avec la version 4.7.2 de gcc.

Une application est caractérisée par :

• N : le nombre de processus (32 dans notre cas).

• M : le nombre total de ressources dans le système (80 dans notre cas).

• α : le temps d’exécution de la section critique (variable entre 5 ms et 35 ms selon le nombre de ressources demandées).

• β : l’intervalle de temps entre le moment où un processus libère la section critique et le moment où il la redemande.

• γ : la latence réseau pour envoyer un message entre deux processus.

• ρ : le rapport β/(α + γ), qui exprime la fréquence à laquelle la section critique est demandée. La valeur de ce paramètre est inversement proportionnelle à la charge en requêtes : une valeur basse donne une charge haute et vice-versa. Dans nos expériences, nous avons considéré une charge haute et moyenne.

• SizeReq : le nombre maximum de ressources qu’un site peut demander. Ce para-mètre est compris entre 1 et M .

À chaque nouvelle requête, un processus choisit x ressources uniformément entre 1 et SizeReq. Le temps de section critique de la requête dépend alors de la valeur de x : plus cette valeur est grande et plus le temps de section critique risque d’être grand car nous considérons qu’une requête demandant beaucoup de ressources doit en pratique avoir un

7.4. Évaluation 107 plus grand temps de calcul en section critique.

7.4.2 Résultats sur le taux d’utilisation

La métrique principale pour l’évaluation des algorithmes est le taux d’utilisation. Cette métrique globale est le pourcentage de temps où les ressources sont utilisées. On peut la voir comme le pourcentage de l’aire colorée des diagrammes de la figure 7.3. Ainsi, la figure 7.3(a) donne un exemple d’exécution où les ressources ne sont pas utilisées efficacement alors que la figure 7.3(b) illustre une exécution avec un meilleur taux d’utilisation (zone blanche moins importante).

(a) Exécution peu efficace (b) Exécution efficace

Figure 7.3 – Illustration du taux d’utilisation pour l’exclusion mutuelle généralisée

Sur les graphiques de la figure 7.4, nous faisons varier en abscisse la taille maximale des requêtes (paramètre SizeReq). Les figures 7.4(a) et 7.4(b) montrent l’impact de ce paramètre sur le taux d’utilisation respectivement en moyenne et haute charge. L’aug-mentation de la taille maximale fait varier deux facteurs :

• la taille moyenne des requêtes qui aura un effet positif sur la métrique : on utilise plus de ressources à chaque section critique

• le nombre de conflits qui aura un effet négatif sur la métrique : la parallélisation des requêtes est plus difficile.

Performances globales

Dans la figure 7.4 nous avons ajouté une courbe témoin représentant un algorithme en mémoire partagée ayant une connaissance globale des nouvelles requêtes émises et un coût de synchronisation nul. Cette connaissance globale lui permet d’ordonnancer les requêtes afin d’utiliser au mieux les ressources. Ainsi, l’écart avec cette courbe donnera le coût de synchronisation des algorithmes. En cas de charge moyenne, nous pouvons voir que l’im-pact des conflits est toujours moins important que le facteur taille (les courbes augmentent en permanence). En revanche, nous remarquons qu’en forte charge le comportement global passe par trois phases :

108 Chapitre 7. Verrouiller efficacement les ressources sans connaissance préalable des conflits 0 10 20 30 40 50 60 10 20 30 40 50 60 70 80

taux d’utilisation des ressources (%)

Taille maximale des requêtes

Incremental Bouabdallah Laforest Politique equitable Petites requetes prioritaires en mémoire partagée

(a) Taux d’utilisation en moyenne charge

0 10 20 30 40 50 60 10 20 30 40 50 60 70 80

taux d’utilisation des ressources (%)

Taille maximale des requêtes

Incremental Bouabdallah Laforest Politique equitable Petites requetes prioritaires en mémoire partagée

(b) Taux d’utilisation en haute charge Figure 7.4 – Impact sur le taux d’utilisation

• en cas de petites requêtes : la courbe augmente car le facteur de la taille moyenne est plus important que le facteur conflit.

• en cas requêtes de taille inférieure à la moyenne : le facteur conflit reprend le dessus sur le facteur taille.

• en cas de requête de taille supérieure à la moyenne : la courbe augmente de nouveau grâce au facteur taille qui redevient plus important que le facteur conflit.

Les requêtes de taille moyenne sont donc les plus coûteuses en matière de taux d’utilisation car leur taille est assez grande pour générer des conflits mais trop insuffisante pour avoir un taux d’utilisation important.

Performances des algorithmes distribués

Une première remarque sur ces résultats, est que l’algorithme incrémental ne suit en aucun cas le comportement global du taux d’utilisation. En effet, il ne fait que diminuer à cause de l’effet domino. L’algorithme de Bouabdallah-Laforest ne profite pas du paral-lélisme potentiel lorsqu’il y a peu de conflits à cause de sa section critique de contrôle qui est très coûteuse en synchronisation.

De manière générale, notre algorithme permet d’avoir un meilleur taux d’utilisation car il réduit les communications entre processus non conflictuels. On peut remarquer une différence entre les deux politiques : la deuxième politique donnant une priorité aux petites requêtes a un taux d’utilisation moins important que la première politique lorsque la taille maximale augmente. Ceci s’explique par le fait que les requêtes de tailles moyennes (les plus coûteuses en termes de dégradation du taux d’utilisation comme nous avons pu le voir précédemment) sont privilégiés par rapport aux requêtes de taille plus importante qui sont dans cette politique moins prioritaires alors qu’elles maximisent l’utilisation des ressources. Ainsi, on pouvait penser que favoriser les requêtes de petites tailles améliorerait le taux d’utilisation grâce à leurs faibles impacts en termes de conflits. Cette solution n’est donc pas satisfaisante.