bruno roggeri & r´emi lallement 20 ... - campus de metz

Rapport de projet de developpement logiciel

Bruno Roggeri & Remi Lallement

20 janvier 2005

Resolution du probleme des N reines en multithreading

Table des matières

1 Dossier de specification 71.1 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.1 Objectifs principaux . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4.2 Objectifs secondaires . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Plan des tests 11

3 Dossier de conception 153.1 Architecture du programme . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 Interactions entre les interfaces utilisateurs et les methodes deresolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.2 Gestion des parametres . . . . . . . . . . . . . . . . . . . . . . . . 163.1.3 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Algorithmes et methodes de parallelisation . . . . . . . . . . . . . . . . . . 173.2.1 Methode de resolution sequentielle par backtracking primaire . . . 17

3.2.1.1 Principe de l’algorithme . . . . . . . . . . . . . . . . . . . 173.2.1.2 Representation des donnees . . . . . . . . . . . . . . . . . 18

3.2.2 Methode de resolution sequentielle par backtracking utilisant lescolonnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.2.1 Principe de l’algorithme . . . . . . . . . . . . . . . . . . . 183.2.2.2 Representation des donnees . . . . . . . . . . . . . . . . . 18

3.2.3 Methode de resolution sequentielle par backtracking utilisant lescolonnes et les diagonales . . . . . . . . . . . . . . . . . . . . . . . 183.2.3.1 Principe de l’algorithme . . . . . . . . . . . . . . . . . . . 183.2.3.2 Representation des donnees . . . . . . . . . . . . . . . . . 18

3.2.4 Utilisation des symetries . . . . . . . . . . . . . . . . . . . . . . . . 193.2.4.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.5 Methode de resolution parallelisee statiquement . . . . . . . . . . . 193.2.5.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.5.2 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.5.3 Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.6 Methode de resolution parallelisee dynamiquement . . . . . . . . . 203.2.6.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3

3.2.6.2 Diagrammes des classes et de deploiement des objets . . 213.2.6.3 Exemple de diagramme de sequence . . . . . . . . . . . . 22

3.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.1 L’interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.2 L’interface console . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Tests 25

5 Documentation 275.1 Manuel de l’interface console . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Manuel de l’interface graphique . . . . . . . . . . . . . . . . . . . . . . . . 28

6 Experimentations 316.1 Comportement des differentes implementations de la machine virtuelle . . 31

6.1.1 Test du compteur multithreade . . . . . . . . . . . . . . . . . . . . 316.1.1.1 Protocole de mesure . . . . . . . . . . . . . . . . . . . . . 326.1.1.2 Comparaison des courbes de temps en fonction du nombre

de threads . . . . . . . . . . . . . . . . . . . . . . . . . . 356.1.1.3 Speed-ups de niveau 1 . . . . . . . . . . . . . . . . . . . . 366.1.1.4 Speed-ups de niveau 2 . . . . . . . . . . . . . . . . . . . . 39

6.1.2 Utilisation reelle avec le probleme des 14 reines . . . . . . . . . . . 406.1.2.1 Speed-ups de niveau 1 . . . . . . . . . . . . . . . . . . . . 416.1.2.2 Speed-ups de niveau 2 . . . . . . . . . . . . . . . . . . . . 43

6.2 Parametres optimaux pour la parallelisation dynamique . . . . . . . . . . 45

4

Introduction

Le probleme des N reines consiste a placer, sur un damier carre de N fois N cases, Nreines (au sens du jeu d’echecs) sans qu’aucunes d’elles ne soient en prise.

Exemple de solution pour N=4 :

Fig. 0.1: Solution possible du probleme des 4 reines

L’objet de ce projet est de trouver un algorithme pouvant utiliser les capacites d’unemachine multi-processeurs permettant de resoudre le probleme le plus rapidement pos-sible.

5

Dossier de spécification 11.1 Objectif

Le but de ce projet est bien sur de resoudre le probleme des N reines, et cela le plusrapidement possible, en utilisant eventuellement les possibilites offertes par les machinesmulti-processeurs. A cette fin, nous souhaitons developper une interface aussi pratiqueque possible qui nous permettra de tester facilement differentes methodes de resolutionet de gestion des threads, de comparer leurs performances et de sauvegarder les resultatsobtenus.

1.2 Cas d’utilisation

Le logiciel ne se destine qu’a un seul type d’acteur : les utilisateurs souhaitant resoudrele probleme des N reines. Il doivent pouvoir choisir la taille du probleme, la methode deresolution, ses parametres, et le traitement eventuel des resultats obtenus.

Fig. 1.1: Cas d’utilisation

7

1.3 Scenario

Fig. 1.2: Scenario

1.4 Cahier des charges

1.4.1 Objectifs principaux

Nous souhaitons elaborer plusieurs methodes de resolution et disposer d’un outilpermettant de comparer facilement leurs performances. En particulier nous souhaitonsdevelopper une interface utilisateur graphique permettant de choisir simplement la tailledu probleme et la methode de resolution ainsi que ses eventuels parametres, et permet-tant de mesurer les temps d’execution.

Nous nous fixons comme objectif de realiser au moins un de chacun des principauxtypes d’algorithme suivants :

– Un algorithme sequentiel monothread– Un algorithme multithread avec gestion statique des threads– Un algorithme multithread avec gestion dynamique des threads

1.4.2 Objectifs secondaires

Selon le temps qui aura ete necessaire a la realisation des objectifs principaux, nousaimerions pouvoir essayer plusieurs methodes d’un meme type pour tenter d’optimiser

8

les performances (exemple : pour un algorithme avec gestion statique des threads, jouersur les decoupages possibles de l’arbre de recherche).

Eventuellement, nous pourrions aussi regarder s’il est possible d’introduire une partde recursivite dans la resolution du probleme des N reines, c’est-a-dire s’il est possiblede reutiliser les solutions du problemes pour un N inferieur.

On pourrait aussi s’interesser a des manieres amusantes d’afficher les solutions trouveeset d’illustrer les algorithmes utilises. Enfin, il serait interessant de pouvoir creer desjournaux gardant une trace des resultats obtenus, avec la methode de resolution, letemps d’execution et la machine utilisee.

9

Plan des tests 2

Nous avons ici separe les tests concernant l’interface graphique, l’interface console, etles differentes methodes de resolution.

11

#ID Test Technique de testIG-1 Demarrage : affichage de la fenetre Lancement du programmeIG-2 Selection de la taille du damier Action sur le menu deroulant

correspondantIG-3 Selection de la methode Action sur le menu deroulant

correspondantIG-4 Affichage dynamique des

parametresSelection successive de differentes

methodesIG-5 Selection des parametres

supplementairesTests repetes pour chaque methode

l’exigeantIG-5.1 Parametre de la methode

parallelisee statiqueAction sur le menu deroulant

correspondantIG-5.2 Parametre de la methode

parallelisee statique + symAction sur le menu deroulant

correspondantIG-5.3 Parametres de la methode

parallelisee dynamiquementAction sur le menu deroulant

correspondantIG-6 Lancement du calcul Action sur le bouton « Lancer »

IG-6.1 Desactivation du bouton« Lancer »

Observation directe

IG-6.2 Affichage : « Execution en cours » Observation directeIG-6.3 Indicateur d’activite Observation : l’indicateur doit

clignoterIG-7 Fin du calcul : affichage du resultat Observation directeIG-8 Reactivation du bouton « Lancer » Observation directeIG-9 Affichage du temps d’execution Observations repetees, coherence,

et chronometrageIG-10 Fermeture du programme Fermer la fenetre, verifier au

niveau de l’OS

Tab. 2.1: Tests de l’interface graphique

12

#ID Test Technique de testIC-1 Demarrage : affichage du message

d’accueilLancement du programme

IC-2 Affichage des messages d’aide Tests avec parametres errones, man-quants ou superflus

IC-3 Selection de la taille du damier Lancement avec des parametres cor-rects

IC-4 Selection de la methode Lancement avec des parametres cor-rects

IC-5 Selection des parametressupplementaires

Lancement avec des parametres cor-rects

IC-6 Indicateur d’activite ObservationIC-7 Affichage des solutions Tests avec les premieres methodes

sequentiellesIC-8 Affichage du nombre de solutions Observation directeIC-9 Affichage du temps d’execution Observations repetees, coherence, et

chronometrageIC-10 Fermeture du programme a la fin du

calculVerification au niveau de l’OS

Tab. 2.2: Tests de l’interface console

13

#ID Test Technique de testM-1 Resultat par la methode sequentielle

de backtracking simpleComparaison avec la litterature etles autres methodes

M-2 Resultat par la methode introdui-sant le placement par colonne

Comparaison avec la litterature etles autres methodes

M-3 Resultat par la methode introdui-sant le stockage des etats des ligneset des diagonales


M-4 Resultat par la methode introdui-sant l’utilisation de la symetrie


M-5 Resultat par la methode paralleliseede maniere statique n’utilisant pasles symetries


M-6 Resultat par la methode paralleliseede maniere statique utilisant lessymetries


M-7 Resultat par la methode paralleliseede maniere dynamique


Tab. 2.3: Tests des methodes

14

Dossier de conception 33.1 Architecture du programme

Dans le but de pouvoir facilement ajouter de nouvelles methodes de resolution eteventuellement de nouvelles interfaces, le programme a ete architecture de maniere aetre modulaire.

3.1.1 Interactions entre les interfaces utilisateurs et les methodes deresolution

Toutes les methodes de resolution sont des classes implementant l’interface Methode-DeResolution. Cette interface demande la definition de quelques operations permettantl’identification de la methode et la description des parametres qu’elle necessite, maissurtout impose la creation d’une operation lancer. Celle-ci effectuera la resolution duprobleme des N reines en utilisant la methode en question.

Reciproquement, toutes les interfaces pouvant etre utilisees pour choisir une methodede resolution ainsi que ses parametres, la lancer, et gerer le retour des resultats al’utilisateur, doivent implementer l’interface UInterface. Cette interface impose troisoperations. La plus importante est l’operation afficherNbreSolutions, qui sera utiliseepar une methode de resolution pour retourner le nombre de solutions trouvees a lafin du calcul. Les deux autres sont « optionnelles », au sens ou il n’est pas primor-dial qu’elles effectuent une action, ni qu’une methode de resolution ne les declenche.L’operation afficherSolution permet le retour eventuel d’une representation d’une solu-tion vers l’interface sous la forme d’une matrice N×N de booleens, tandis que l’operationsignalerSolution permet de signaler la decouverte d’une nouvelle solution et peut servira implementer un indicateur d’activite sans pour autant specifier la solution trouvee.

Souvent, nous n’utiliserons pas la methode afficherSolution car elle peut s’averer assezcouteuse. Elle n’est d’ailleurs pas implementee dans l’interface graphique que nous avonscreee, mais seulement dans l’interface console, et seules les premieres methodes y fonteffectivement appel.

De meme, signalerSolution n’est implementee que dans l’interface graphique, car nousne nous sommes pas donnes la peine de doter l’interface console d’un indicateur d’acti-vite. Elle est par contre utilisee par toutes les methodes de resolutions que nous avonsdeveloppees.

15

Pour que chaque interface soit automatiquement associee a toutes les methodes exis-tantes, nous avons de plus cree une classe intermediaire Methodes qui rassemble toutesles methodes de resolution dans un tableau. Ainsi, en ne modifiant que cette derniereclasse, toutes les interfaces ont directement acces a l’ensemble des methodes.

3.1.2 Gestion des parametres

Dans un premier temps, les methodes que nous avions implementees ne demandaientqu’un seul parametre evidemment indispensable : N , le nombre de cases sur un cote dudamier, ou autrement dit le nombre de reines a placer dessus. Ce parametre etait doncnaturellement place en argument de la methode lancer.

Mais quand nous avons commence a developper des methodes parallelisees, nousavons eu besoin d’introduire un autre parametre : le nombre de threads. En antici-pant l’implementation de nouvelles methodes qui pourraient necessiter un nombre ar-bitraire de parametres autres que la taille du probleme, nous avons voulu doter notreprogramme d’un mecanisme permettant aux interfaces de s’adapter automatiquement achaque methode de resolution.

Pour ce faire, nous avons cree une classe Parametres permettant de decrire d’unemaniere standard les parametres d’une methode, et associe a chaque methode de resolutionune instance de cette classe. Les interfaces pourront donc, pour chaque methode deresolution, recuperer la description des parametres qui lui sont necessaires et s’adapterpour permettre a l’utilisateur de specifier ces parametres. La description des parametrescomprend le nombre de parametres attendus, leurs noms et l’ensemble des valeurs qu’ilspeuvent prendre. A charge de l’interface de s’assurer que les parametres specifies parl’utilisateur sont valides.

Cette meme classe permet a l’interface de communiquer les parametres choisis parl’utilisateur a la methode de resolution avant l’appel de l’operation lancer, ceci a l’aide del’operation setParametre qui permet de donner une certaine valeur a un des parametresde la methode. La methode de resolution pourra alors a son tour recuperer les parametreschoisis grace a l’operation getParametre.

Il est vrai que, en pratique, nous n’avons pas implemente de methodes demandant plusd’un autre parametre que N . Notre demarche peut donc sembler un peu trop compliqueepar rapport a nos besoins. Toutefois, generaliser le probleme a ce niveau nous a permisde conserver un code plus simple au sens ou nous n’avons pas du nous embarrasser dela gestion des differents cas independemment les uns des autres, ce qui aurait brise lamodularite du programme.

3.1.3 Diagramme des classes

Le diagramme des classes suivant decrit cette l’architecture. On peut y voir plusprecisement comment la classe Parametres a ete implementee, ainsi que toutes les inter-actions decrites dans les paragraphes precedents.

16

Fig. 3.1: Diagramme des classes

3.2 Algorithmes et methodes de parallelisation

3.2.1 Methode de resolution sequentielle par backtracking primaire

3.2.1.1 Principe de l’algorithme

S’il y a de la place sur le damier pour une nouvelle reine, on place une nouvelle reinedans une des places libres, et on recommence. Si par contre il n’y a plus de place, onverifie d’une part que toutes les reines n’ont pas ete placees (auquel cas on vient detrouver une solution), et d’autre part qu’il reste bien des reines sur le damier. S’il n’enreste aucune, c’est fini, sinon, on enleve la derniere reine placee, on marque l’endroit ouelle etait comme etant inutilisable, et on recommence.

17

3.2.1.2 Representation des donnees

Dans cet algorithme, on represente le damier par une matrice N×N de booleens. Si unelement de la matrice est VRAI, la case correspondante est inutilisable, soit parce qu’unereine est dessus, soit parce qu’une reine la menace, soit parce qu’on a deliberement cochela case pour ne pas y revenir.

3.2.2 Methode de resolution sequentielle par backtracking utilisant lescolonnes


On utilise le fait que toutes les solutions auront une seule reine par colonne. On cherchedonc a placer chaque reine sur sa colonne.

Si la reine de la prochaine colonne peut etre placee sans etre en prise avec une desreines deja placees dans une des colonnes precedentes, alors on l’y met, et on passe a lareine de la colonne suivante. Si par contre ce n’est pas possible, on revient a la reine dela colonne precedente, en on recommence.

On a une solution des qu’on a pu placer chaque reine sur sa colonne. Dans ce cas oncontinue comme si la prochaine reine ne pouvait pas etre placee (il n’y a d’ailleurs pasde prochaine reine), donc en cherchant une nouvelle position pour la reine de la dernierecolonne. L’algorithme se termine quand on n’arrive plus a placer la premiere reine.


L’etat du damier est represente par un tableau de taille N contenant les positions dechacune des reines dans leur colonne.

3.2.3 Methode de resolution sequentielle par backtracking utilisant lescolonnes et les diagonales


Meme principe que l’algorithme precedent, sauf que l’on prend note des lignes et desdiagonales occupees, ce qui permet de tester tres rapidement si une position est valable,au lieu de devoir verifier les interactions avec chacune des reines deja placees.


L’etat du damier est represente par un tableau d’entiers de taille N contenant lespositions de chacune des reines dans leur colonne. De plus, 3 autres tableaux de booleensde taille N servent a noter quelles sont les lignes / diagonales / antidiagonales libres.

18

3.2.4 Utilisation des symetries

3.2.4.1 Principe

On reprend l’algorithme, mais on prend garde maintenant a ne calculer que les so-lutions dont la premiere reine se situe sur la premiere moitie de sa colonne. Les autressolutions s’obtiennent par symetrie verticale. Pour les tailles de damier impair, on rajoutele nombre de solutions dont la premiere reine se situe au milieu de sa colonne. Ce nombreest calcule en utilisant a nouveau la symetrie verticale, qui a ete conservee puisque lapremiere reine est au milieu. On ne considere donc que les solutions dont la deuxiemereine est sur la premiere moitie de sa colonne. On peut meme systematiquement eviterla derniere position de la premiere moitie puisque la premiere reine la bloque.

Fig. 3.2: Utilisation de la symetrie

3.2.5 Methode de resolution parallelisee statiquement

3.2.5.1 Principe

L’algorithme est le meme que celui utilise pour la methode du paragraphe 3.2.3. Maison introduit maintenant un nouveau parametre : le nombre de threads sur lesquelsnous allons repartir la charge de travail. La repartition est faite de maniere statique :chaque thread se voit assigner au demarrage du programme une partie du probleme totalcaracterise par l’ensemble des positions de la premiere reine qu’il doit explorer.

3.2.5.2 Contraintes

La repartition en differents threads n’est pas gratuite : pour chaque nouveau thread ilfaut recreer un environnement (tableau des positions et tableaux gardant trace de l’etatdes lignes et des diagonales) qui lui soit propre afin que les threads n’interferent pasentre eux

3.2.5.3 Evolution

On peut bien sur utiliser les memes symetries proposees au 3.2.4.

19

3.2.6 Methode de resolution parallelisee dynamiquement

3.2.6.1 Principe

La methode de parallelisation precedente avait l’inconvenient de donner aux differentsthreads des taches qui pouvaient etre de longueurs assez differentes les unes des autres.Un thread qui finissait sa tache bien avant les autres ne faisait alors plus aucun travail.Une solution pouvait consister a lancer plus de threads qu’il n’ y a de processeurs, de sortea avoir des taches plus petites et donc potentiellement de longueurs moins disparates.Mais les performances dependent alors grandement du comportement de l’ordonnanceur,qui s’est avere etre assez aleatoire. De plus, cette astuce augmente le temps passe a creerdes threads.

Pour pallier a ce probleme, nous avons utilise un systeme de producteur / consomma-teurs. Le thread principal de la methode va se charger de diviser le probleme initial ensous-problemes plus petits et les mettre dans une file d’attente, tenant ainsi le role deproducteur. Cette tache est ici accomplie en placant un certain nombre d des premieresreines de maniere sequentielle. Un nouveau probleme a traiter est ainsi mis en file achaque fois que le producteur arrive a placer d reines. d est caracteristique du degre dedivision du probleme initial.

Les threads consommateurs iront chercher dans cette file d’attente un sous-problemeet le traiteront. Des qu’un thread consommateur a termine sa tache, il peut sans attendrepiocher un autre probleme dans la file d’attente. Ainsi, le temps durant lequel un threadpeut se retrouver sans travail alors qu’il en reste encore a faire est tres faible.

Cette methode accepte donc deux parametres dont il pourra etre interessant d’etudierl’influence sur les performances : le nombre de threads consommateurs p et le degre dedivision d.

Fig. 3.3: Schema de la parallelisation dynamique

Dans le schema ci-dessus, les zones du damier en traits solides correspondent a l’espace

20

dans lequel le thread en question doit placer des reines.

3.2.6.2 Diagrammes des classes et de deploiement des objets

Fig. 3.4: Diagramme des classes

Fig. 3.5: Schema de deploiement des objets

21

3.2.6.3 Exemple de diagramme de sequence

Voici un diagramme de sequence pour le scenario ou l’utilisateur lance la methode deresolution parallelisee dynamique par l’intermediaire de l’interface console.

3.3 Interfaces

3.3.1 L’interface graphique

Losque nous avons commence a developper l’interface graphique, nous ne disposionsque de methodes sequentielles de resolution. Ainsi, pour ce qui est du choix des pa-rametres, nous n’avions qu’a nous occuper de la taille du damier, et du choix de lamethode. Nous avons donc divise l’unique fenetre de notre interface en deux panneaux :l’un contenant les boıtes dediees a la selection des differents parametres ainsi qu’un

22

bouton servant a lancer le calcul, et l’autre ou s’affichaient les resultats, c’est-a-dire lenombre de solutions trouvees et la duree d’execution.

Lors du calcul des solutions pour un probleme de taille relativement elevee (typique-ment, a partir de N = 15), il est apparu que la presence d’un « indicateur d’activite »serait pertinente afin de savoir, quand l’execution s’eternise un peu, si le programmecontinue de tourner ou si la machine a plante. Il se presente sous la forme d’un ca-ractere, visible sur le panneau contenant les resultats du calcul, qui prend tour a tourla forme * ou # au fur et a mesure que des solutions au probleme sont trouvees. Nousavons pour cela ajoute l’operation signalerSolution dans la classe UInterface.

Quand il a fallu rendre les methodes de resolution parallelisees disponibles depuisl’interface graphique, nous avons du ajouter un troisieme panneau a la fenetre, afinde pouvoir rentrer de nouveaux parametres, comme le nombre de threads utilises, parexemple. Comme nous l’avons explique au paragraphe 3.1.2, nous avons cree une classeParametres afin que les interfaces aient acces facilement aux parametres exiges par lesdifferentes methodes de resolution. Dans le cas de l’interface graphique, ceci a pour effetde rendre visible dans le troisieme panneau des boıtes permettant la selection de cesparametres. Cet affichage se met a jour a chaque fois qu’une methode est selectionnee.

3.3.2 L’interface console

L’interface console a deux utilites. D’une part, elle a pu etre developpee rapidement eta servi pour faire les premiers tests. Une fois que l’architecture du programme expliciteedans la section 3.1 a ete mise en place de facon satisfaisante, nous avons pu coder lesmethodes de resolution et les interfaces en parallele. Mais jusque la, c’etait la seule inter-face que nous pouvions utiliser. D’autre part, l’interet de notre projet etant d’utiliser desmachines multi-processeurs, qui en l’occurence ne proposaient pas forcement d’interfacegraphique, il etait capital de disposer d’une interface qui fonctionnerait sur un maximumde machines.

Le principe de l’interface est classique : les parametres (taille du probleme, numerode methode, puis parametres supplementaires eventuels) sont passes directement sur laligne de commande. Si les parametres ne sont pas valides, un message expliquant lefonctionnement de l’interface est imprime a l’ecran.

23

Tests 4#ID Reussite CommentairesIG-1 OuiIG-2 OuiIG-3 OuiIG-4 OuiIG-5 Oui

IG-5.1 OuiIG-5.2 OuiIG-5.3 OuiIG-6 Oui

IG-6.1 OuiIG-6.2 OuiIG-6.3 OuiIG-7 OuiIG-8 OuiIG-9 OuiIG-10 OuiIC-1 OuiIC-2 Non La signification et le nombre de parametres supplementaires

des methodes en necessitant n’est pas affichee. Tous lesautres parametres sont cependant expliques.

IC-3 OuiIC-4 OuiIC-5 OuiIC-6 Non L’indicateur n’est pas implemente. Nous ne souhaitons pas

vraiment le faire afin de disposer d’une interface qui ne ra-lentit pas le calcul.

IC-7 OuiIC-8 OuiIC-9 OuiIC-10 OuiM-1 Oui

25

M-2 OuiM-3 OuiM-4 OuiM-5 OuiM-6 OuiM-7 Oui

26

Documentation 55.1 Manuel de l’interface console

Cette interface s’utilise entierement en mode texte : tous les parametres sont directe-ment passes sur la ligne de commande. La syntaxe est relativement simple :

$ java InterfaceConsole taille damier n methode [param methode1, ... ]

Les parametres supplementaires des methodes qui en utilisent sont obligatoires. L’entreede parametres non valides ou l’omission de parametres entraıne l’affichage d’un messagerappelant la syntaxe de la commande.

Les numeros des methodes peuvent etre obtenus en tapant simplement :

$ java InterfaceConsole

Ce qui donnera par exemple :

Utilisation : java InterfaceConsole taille damier methode choisie[autres parametres obligatoires si la methode les requiert].

taille damier doit etre un entier strictement positif

methode choisie doit correspondre a une de ces methodes :0 : Resolution sequentielle par backtracking primaire1 : Resolution sequentielle par backtracking utilisant les colonnes2 : Resolution sequentielle par backtracking utilisant les colonneset les diagonales3 : Resolution sequentielle par backtracking utilisant des symetriesdu probleme4 : Resolution Parallelisee de maniere statique5 : Resolution Parallelisee de maniere statique utilisant une partiedes symetries6 : Resolution Parallelisee de maniere dynamique

27

5.2 Manuel de l’interface graphique

On lance cette interface en tapant :

$ java InterfaceGraphique

S’affiche alors la fenetre suivante :

On choisit la taille du probleme a traiter et la methode de resolution grace auxboıtes correspondantes. Lorsque la methode selectionnee requiert un ou des prametressupplementaires, de nouvelles boıtes de selection s’affichent, comme ci-dessous.

Cliquez alors sur le bouton «Go ! » pour lancer le calcul. Ce bouton est desactive pen-dant la recherche du nombre de solutions. Un message « Execution en cours » s’affiche.

Si le calcul prend un certain temps, un indicateur d’activite se mettra a clignoter (uncaractere qui prend successivement les formes * et #).

28

A la fin du calcul, le nombre de solutions et le temps d’execution s’affichent. De plus,le bouton « Go ! » redevient actif afin qu’une nouvelle execution puisse etre lancee.

Le programme est quitte par simple fermeture de la fenetre.

29

Expérimentations 6La multiplication des methodes de resolutions developpees ci-dessus, de leur parametres

eventuels, des machines physiques sur lequel le code a pu etre teste, et enfin des implementationsde la machine virtuelle Java, nous a tenu un moment a l’ecart du projet initial : resoudrele probleme des N reines le plus rapidement possible.

Nous n’avons donc pas pu nous lancer dans un comparatif exhaustif de toutes lesconfigurations possibles, mais nous nous sommes plutot concentres sur 2 points qui nousont semble interessants.

Premierement, suite a un petit probleme pendant le developpement, nous nous sommesapercus que plusieurs machines virtuelles (ou VM) pouvaient avoir des comportementssensiblement differents, notamment en ce qui concerne la gestion des threads. En effet,certaines VM implementent leur propre ordonnanceur de threads, et les font apparaıtreau niveau de l’OS comme un unique thread, ce qui empeche toute parallelisation. Au delade ce probleme, inexistant avec la plupart des VM recentes, nous avons voulu comparerles performances de certaines VM en terme de rapidite d’execution et d’efficacite deparallelisation.

Deuxiemement, nous avons souhaite etudier plus en detail notre methode de resolutionla plus elaboree - et la plus rapide : la methode parallelisee dynamiquement. Cettemethode utilise notre algorithme sequentiel le plus rapide, et est parallelisee sur unnombre donne de threads suivant un systeme de producteur - consommateurs dans le-quel les donnees echangees sont des sous-problemes dans lesquels un certain nombre dereines est deja place. On peut donc affiner cette methode en jouant sur les 2 parametres« nombre de threads » et « taille des sous-problemes ».

6.1 Comportement des differentes implementations de lamachine virtuelle

6.1.1 Test du compteur multithreade

Nous avons d’abord voulu comparer sur un test simple independant du probleme desN reines la rapidite et les capacites de parallelisation de 3 machines virtuelles :

– SUN 1.4.2 - version client– SUN 1.4.2 - version serveur– IBM 1.4.2

31

Notons que nous avions pense a inclure dans ce panel de VM celle de GCC. Cependant,ses performances etant terriblement plus mauvaises de tout point de vue, nous avonsprefere l’ecarter afin de preserver des courbes lisibles.

Nous avons teste ces VM sur 2 machines physiques :

– infomob - Bi-Xeon 2.8 GHz (avec technologie Hyper-Threading)– quadx1 - Quadri-Pentium III 700 MHz

Il sera egalement interessant de comparer les capacites de parallelisation de ces 2 ma-chines physiques, les 2 processeurs Xeon apparaissant sur infomob comme 4 processeursen raison de l’Hyper-Threading.

Le test utilise est un simple compteur dont la tache est de compter jusqu’a 100 000000. Cette tache peut etre repartie sur un nombre de threads que l’on va faire varier de1 a 10.

6.1.1.1 Protocole de mesure

Des aleas peuvent exister a cause de la possible activite du serveur lors des calculs, deseventuelles differences de vitesse entre plusieurs executions du meme test dues a la miseen cache du programme, ou a cause du comportement plus au moins aleatoire de l’or-donnanceur du systeme d’exploitation. Pour minimiser leur impact, nous avons effectuechaque mesure 10 fois de suite, en utilisant la fonction System.currentTimeMillis(). Surles courbes suivantes, on peut voir les points de donnees tels que nous les avons mesures,ainsi que 3 courbes qui en derivent :

– La courbe de la moyenne– La courbe de la moyenne, apres avoir ecarte pour chaque mesure la valeur maximale– La courbe des minima

32

Sur les 2 exemples ci-dessus, on voit l’interet d’un tel traitement. La courbe de lamoyenne debarassee de la valeur maximale en chaque point est la plus fiable et c’estpourquoi nous utiliserons celle-ci dans la suite de nos experimentations. En effet, onvoit sur la premiere courbe qu’elle a permis de ne pas donner d’importance a des pointsclairement aberrants. Sur la deuxieme courbe, tres reguliere, elle reste coherente avec lespoints obtenus.

34

6.1.1.2 Comparaison des courbes de temps en fonction du nombre de threads

35

Ces courbes nous permettent de constater que la VM d’IBM est la plus rapide surquadx1 alors que c’est la VM serveur de SUN qui l’emporte d’un courte tete sur in-fomob. La VM cliente est logiquement plus lente car elle est optimisee pour les pro-grammes courts n’utilisant pas intensement le processeur, et ne prend donc pas le tempsde precompiler le code puisque le gain que cela apporterait ensuite serait faible.

6.1.1.3 Speed-ups de niveau 1

On represente ici le rapport : « temps d’execution sur un seul thread » / « tempsd’execution pour le nombre de threads specifie ». Dans un systeme ideal indefinimentparallelisable, ce rapport est une droite y = x. On sera en realite limite bien sur par lenombre de processeurs mais aussi par les overheads.

36

On constate que cette fois-ci c’est la VM client de SUN qui s’en sort le mieux, suivie audebut de pres par la VM serveur de SUN. La difference est particulierement remarquablesur infomob, ou les 2 autres machines virtuelles ne parviennent pas a se paralleliser avecefficacite. Sur quadx1, le resultat est le meme bien que l’ecart soit moins imposant.Surpris par ce phenomene, nous nous sommes d’abord demande s’il n’etait pas du aune sous-evaluation des performances de la VM client pour un seul thread, mais les 10mesures effectuees sont tres regulieres, ce qui ecarte cette eventualite.

Nous ne sommes pas surs des raisons de cette superiorite de la VM client. Cependant,nous nous permettrons d’avancer une hypothese :

On constate que sur infomob, pour les VM IBM et SUN serveur, les performanceschutent avec l’introduction d’un troisieme thread. La VM client a peut-etre plus ten-dance a rendre spontanement la main a l’ordonnaceur, de sorte les trois threads sontequitablement partages et finissent presque tous en meme temps. Les VM « serveurs »,elles, si elles gardent longtemps la main, executent les 2 premiers threads d’une traite,et se retrouvent a moitie au « chomage » lorsqu’il ne reste plus qu’un thread.

Il apparaıt le meme phenomene sur quadx1 pour 5 threads, mais ici, etrangement,toutes les VM sont touchees.

En tout cas, ceci n’explique pas non plus que sur infomob, la VM client puisse obtenirdes speed-ups legerement superieurs a 2 pour un nombre de threads plus important. Ceciest peut-etre du a l’Hyper-Threading, ou a des gains de temps au niveau de l’execution

38

de threads qui partagent le meme code et n’ont peut-etre pas besoin d’etre recompiles.

Sinon globalement les performances sont bonnes pour un nombre de threads egal aunombre de processeurs : on obtient des speed-ups proches de 4 sur quadx1.


On represente le rapport « meilleur temps d’execution sur un seul thread » / « tempsd’execution pour le nombre de threads specifie». On pourra ainsi visualiser si la meilleureparallelisation d’une des VM de SUN lui permet de rattraper les performances de la VMd’IBM sur quadx1.

39

On constate, comme plus haut bien sur, que la VM d’IBM garde malgre tout sonavantage. On remarque aussi que quelle que soit la VM, le nombre de threads optimalsemble etre le nombre de processeur de la machine, et cela sans que le fait que lesprocesseurs soient « Hyper-Threades » n’ait une influence notable.

Sur infomob, SUN serveur et IBM se partagent les premieres places, mais c’est SUNqui est la plus performante avec le plus haut point du graphe pour 2 threads.

6.1.2 Utilisation reelle avec le probleme des 14 reines

On utilise ici les memes machines virtuelles et physiques, ainsi que le meme protcolede mesure pour eviter les aberrations. Mais le test utilise est maintenant la resolutiondu probleme des 14 reines par la methode de resolution parallelisee dynamiquement.

Derniere minute : suite a des mesures aberrantes lors du test de la VM serveur surinfomob, les graphes suivants contiennent des informations erronees.

40


41


43

On constate que la VM garde le monopole de la vitesse d’execution sur quadx1.

44

6.2 Parametres optimaux pour la parallelisation dynamique

On voit apparaıtre sur ce graphe ou l’algorithme atteint des minimums de tempsd’executions : celui qui correspond a 4 threads avec une profondeur de division de 1,et celui a 2 threads avec une profondeur de division de 5. On ne peut pas se baser surtelles mesures pour decider quels sont les meilleurs parametres pour cette fonction surd’autre machine, et avec N<>15. Cependant on peut remarquer que le schema « nombrede threads = nombre de processeurs » reste une valeur sure.

45

Conclusion

Du point de vue de notre cahier de charge, ce projet est objectivement une reussite.Tous les objectifs principaux ont ete atteints : nous disposons de plusieurs methodes,implementant successivement des optimisations supplementaires, et nous les avons pa-rallelisee de maniere a pouvoir profiter de maniere satisfaisante des capacites de machinesmultiprocesseurs. Nous avons pu aussi nous interesser a une bonne partie des objectifssecondaires. En particulier l’archivage des resultats des tests a pu etre effectue et a etel’occasion de nous familiariser avec la gestion des entrees / sorties en Java, ce qui nous futegalement utile pour generer automatiquement les fichiers textes qui nous ont permis detracer les courbes de ce rapport a partir des resultats de tests precedemment serialises.

Cependant, il reste encore beaucoup de choses qu’il pourrait etre interessant d’essayer.Notamment, nous aurions bien voulu implementer un algorithme travaillant sur les

permutations des N reines, ce qui nous aurait permis de faire un backtracking sur unarbre dont chaque noeud a un fils de moins que son pere, au lieu de le faire sur unarbre dont chaque noeud a N fils. Il est a noter que le gain de temps d’un tel algorithmene sera sans doute pas immediat, car d’une part, passer a la position suivante (quiest l’operation la plus repetee de l’algorithme de backtracking) necessite maintenant degenerer la permutation suivante, ce qui est un peu plus couteux (mais toujours en O(1)) que de simplement incrementer la derniere reine, et d’autre part, les positions que l’onevite grace a la generation de permutation sont des positions qui n’aurait pas donne lieua un sous-arbre de recherche. Le gain de temps ne se ferait donc sans doute sentir qu’apartir d’un N assez grand. Il aurait donc ete egalement instructif de mesurer si cettemethode aurait ete avantageuse.

Il aurait aussi ete logique de continuer de developper l’interface graphique pour nouspermettre d’effectuer les operations d’archivage par son intermediaire. De meme, l’inter-face console necessiterait une petite amelioration du systeme d’aide qui n’indique pasdans quel ordre passer les parametres supplementaires des methodes.

Enfin, il serait egalement raisonnable de ne pas utiliser Java pour faire ce genre cal-cul intensif. Un passage sous un langage plus oriente vers la vitesse d’execution seraitsouhaitable.

47

bruno roggeri & r´emi lallement 20 ... - campus de metz

Documents