M´ethodologie d’analyse et d’exp´erimentation

Analyser les performances de r´esolution d’un solveur de programmation logique avec contraintes (PLC) n’est pas simple, car les m´ecanismes de propagation de contraintes sont r´ealis´es de ma- ni`ere transparente pour l’utilisateur. Sous l’environnement de compilation SICStus Prolog, que nous utilisons pour nos travaux, trois param`etres sont cependant mis `a disposition :

– un param`etre backtrack, afin de connaˆıtre le nombre de retours sur trace op´er´es par l’al- gorithme de recherche ;

– un param`etre memory, qui pr´ecise la quantit´e de m´emoire utilis´ee pour la recherche. Le param`etre de quantit´e m´emoire consomm´ee ne sera que peu regard´e car, bien qu’em- barqu´ee, notre application est peu critique `a cet ´egard. De plus, le compilateur SICStus n’est pas capable de fonctionner avec plus de 256Mo (limite interne d’adressage). Cette limite est cependant conforme `a nos pr´erequis techniques : nous ne nous soucierons donc de ce crit`ere qu’`a but informatif. Nous ´evaluerons les diff´erentes approches `a l’aide des param`etres time et back- track. Comme nous l’avions ´evoqu´e en section 3.2.3, la valeur de temps ´etant d´ependante d’un grand nombre de crit`eres — fr´equence d’horloge et quantit´e de cache du processeur, syst`eme d’exploitation, pr´eemptibilit´e du programme, quantit´e et temps d’acc`es `a la m´emoire vive... —, il n’est pas envisageable de comparer les valeurs de temps de calcul de diff´erentes approches de PLC ex´ecut´ees sur deux machines diff´erentes. Or, dans le cas d’une r´esolution en programmation logique, il n’est pas possible de compabiliser un nombre de cycles comme pr´ec´edemment. Nous disposons du nombre de retours sur trace, mais l`a encore, ces derniers ne sont pas n´ecessairement ´equivalents `a un simple compteur d’appel `a une fonction de programmation imp´erative. En ef- fet, ils ne sont pas le reflet des temps de propagation pouvant ˆetre induits, ces derniers pouvant ˆetre tr`es variables. En conclusion, pour une comparaison fiable, les comparaisons devront ˆetre r´ealis´ees sur une mˆeme station de calcul. De mˆeme, les valeurs de temps et de retour sur trace devront ˆetre analys´ees de mani`ere d´ecoupl´ee.

La m´ethodologie de test est identique `a celle r´ealis´ee pour les comparatifs des algorithmes de colonies de fourmis (voir figure 3.5). Seule la structure de donn´ees, pour la sauvegarde des r´esultats, a ´et´e modifi´ee. Un aper¸cu de cette structure est donn´e par la figure 3.13. Plusieurs diff´erences sont `a noter. Dans cette structure, le type SolvingData rassemble les r´esultats d’une ex´ecution. Ces r´esultats pr´esentent les donn´ees suivantes :

– le temps (optTime) et le nombre de retours sur trace (optBacktracks) pour trouver la solution optimale ;

– le temps (proofTime) et le nombre de retours sur trace (proofBacktracks) pour achever l’ex´ecution, c’est-`a-dire prouver que la derni`ere solution est la solution optimale ;

– le coˆut de la solution optimale (score).

Le solveur de contraintes a un comportement d´eterministe : pour son analyse, une ex´ecution suffit. Pour ´etudier les comportements du solveur pour chaque sonde, il est donc n´ecessaire de le confronter `a plusieurs configurations diff´erentes. Le type Result nous permet de stocker les r´esultats d’une ex´ecution pour une configuration pr´ecise, comportant :

– le nœud de d´epart (startNode) ; – le nœud d’arriv´ee (endNode) ;

– la liste ´eventuelle des nœuds obligatoires (nomm´es inclusions).

Le type Results, enfin, permet de conserver les r´esultats du solveur pour un ensemble de confi- gurations, sur une instance donn´ee.

Le benchmark r´ealis´e porte sur trois sc´enarios de test issus de cas r´eels, fournis par Sagem : – sc´enario 1 : 23 nœuds, 76 arcs ;

– sc´enario 2 : 22 nœuds, 68 arcs ; – sc´enario 3 : 22 nœuds, 74 arcs.

Pour chaque instance, nous avons mis en place 5 jeux de configurations, chaque jeu comportant 10 configurations. Chaque jeu de configuration correspond `a un nombre donn´e de points obligatoires, de 1 `a 5. L’annexe 5.3.4 d´etaille les instances ainsi que les configurations mises en place. Pour chacune des instances, nous avons compar´e, selon le nombre de points obligatoires :

Figure _{3.13 – Sch´ema des structures de donn´ees XML pour l’exp´erimentation du sol-} veur de contraintes (impression-´ecran du logiciel <oXygen/> XML Editor).

– le temps de calcul moyen et maximum d’obtention de la solution optimale ; – le temps de calcul moyen et maximum de preuve d’optimalit´e ;

– le nombre de retours sur trace moyen et maximum d’obtention de la solution optimale ; – le nombre de retours sur trace moyen et maximum de preuve d’optimalit´e.

Trois approches ont ´et´e compar´ees :

– une approche REF (r´ef´erence) sans guidage (pas de tri des variables) ; – une approche SP (shortest path) de guidage avec plus court chemin ; – une approche ANTS de guidage avec colonies de fourmis.

Les r´esultats sont fournis dans la section suivante.

La taille des instances ainsi que le faible nombre de points de passage ne justifient pas ici l’emploi d’un algorithme de r´esolution partielle telle qu’ACO, en raison du faible nombre de combinaisons possibles de s´equences de points de passage. Ces tailles de graphe nous sont impo- s´ees en raison du mod`ele de chemin employ´e au sein du solveur de contraintes. Avec ce mod`ele, qui a l’avantage d’ˆetre g´en´erique, il devient en effet difficile d’obtenir une preuve d’optimalit´e en un temps raisonnable pour des graphes dont la taille d´epasse une trentaine de nœuds. Des essais ont ´et´e bien r´ealis´es sur de grandes instances (telles que celle de la section 3.4.4), permet- tant d’aboutir `a une solution apr`es quelques secondes (le temps de propagation des variables ´etant ici sensible), mais l’absence d’optimalit´e et les temps d’exploration de l’espace d’´etat ne justifie plus l’emploi d’une telle approche. Le choix de la mod´elisation du solveur de contraintes ´etant impos´e, et hors du cadre de cette th`ese, nous devons ici nous y restreindre. Cependant, le choix d’ACO reste coh´erent `a terme en perspective d’une mise `a l’´echelle avec une nouvelle mod´elisation.

Pour cette exp´erimentation, nous traitons un probl`eme sans contrainte de capacit´e. Ainsi, nous pouvons avoir un meilleur aper¸cu de l’efficacit´e intrins`eque du guidage. Cependant, bien que d´epourvu de contrainte, les variables sont pr´esentes dans le mod`ele (initialis´ees dans un domaine [0, 10000]) et propag´ees le long du graphe. Les variables de temps sont exprim´ees en secondes, et la vitesse des v´ehicules est limit´ee `a 30km/h (progression urbaine).

3.3.2 R´esultats et discussion

Les exp´erimentations ont ´et´e men´ees sur un ordinateur portable Samsung Q310, dot´e d’un micro-processeur Intel Core 2 Duo P7350 cadenc´e `a 2GHz et de 3Go de m´emoire vive. La figure 3.14 pr´esente les r´esultats de temps de calcul pour chacune des approches, sur chacune des trois instances (horizontalement). Les graphiques de la colonne de gauche d´ecrivent les temps d’obtention de la solution optimale, ceux de droite les temps de preuve d’optimalit´e. Les histogrammes pr´esentent le temps moyen, en millisecondes et sur 10 ex´ecutions, pour chaque jeu de configurations. Les barres d’erreurs sont ici utilis´ees pour repr´esenter le temps de calcul maximum de la s´erie associ´ee. Structur´es de mani`ere analogue, les r´esultats de nombre de retours sur trace sont pr´esent´es par la figure 3.15.

Nous nous int´eressons en premier lieu au temps de calcul d’obtention des solutions optimales. Tout d’abord, on note que la m´ethode sans guidage pr´esente des performances tr`es m´ediocres sur les instances 1 et 2 (jusqu’`a 35 secondes dans le cas de l’instance 1, ce qui n’est pas repr´esent´e ici). Si elle est a contrario la meilleure sur la 3e

instance, la tr`es grande variabilit´e en termes d’efficacit´e en font une m´ethode `a proscrire dans le cadre applicatif de nos travaux. Concernant les m´ethodes avec guidage, on note que les performances moyennes des deux m´ethodes sont tr`es bonnes sur les instances 1 et 2. On observe que l’approche SP pr´esente n´eanmoins des temps de calcul maximum sensiblement plus ´elev´es que l’approche ANTS sur plusieurs jeux de configurations. Sur l’instance 3, les performances moyennes sont l´eg`erement en de¸ca pour

Figure _{3.14 – Temps de calcul moyens (histogrammes) et maximum (barres d’erreur)} des trois approches REF (sans guidage), SP (guidage par plus court chemin simple) et ANTS (guidage par colonies de fourmis) sur les benchmarks 1,2, et 3 (horizontalement). La colonne de gauche pr´esente les temps d’obtention de la solution optimale ; la colonne de droite pr´esente les temps d’obtention de la preuve d’optimalit´e. Les temps sont donn´es en millisecondes.

Figure_{3.15 – Nombre de retours sur trace moyen (histogrammes) et maximum (barres} d’erreur) des trois approches REF (sans guidage), SP (guidage par plus court chemin simple) et ANTS (guidage par colonies de fourmis) sur les benchmarks 1,2, et 3 (hori- zontalement). La colonne de gauche pr´esente les retours sur trace pour l’obtention de la solution optimale ; la colonne de droite pr´esente les retours sur trace pour l’obtention de la preuve d’optimalit´e.

l’approche ANTS. Cependant, encore une fois, les temps de calcul maximum sont bien mieux «maˆıtris´es ».

En analysant cette fois les temps de calcul d’obtention des preuves d’optimalit´e, on peut noter que les ´ecarts de performances sont moins importants. Pour l’approche sans guidage, le mˆeme constat qu’auparavant peut ˆetre fait : une tr`es bonne efficacit´e sur l’instance 3, mais des performances en de¸ca pour les instances 1 et 2. Pour les m´ethodes avec guidage, on peut noter que les temps de calcul sont globalement similaires sur l’instance 1, et `a l’avantage de l’approche SP sur l’instance 2. Cela va `a l’encontre des r´esultats pr´ec´edents. Ainsi, il est int´eressant de noter que si ANTS am´eliore le temps d’obtention des solutions optimales, elle n’am´eliore cependant pas le temps d’obtention des preuves d’optimalit´e. C’est pourtant ce `a quoi on ´etait en droit de s’attendre : en trouvant la solution optimale plus rapidement, la r´esolution par s´eparation-´evaluation est en th´eorie capable d’´elaguer l’arbre de recherche plus efficacement. Sachant que l’approche ANTS fournit une solution partielle qui est le chemin de distance mi- nimum parcourant l’ensemble des points oblig´es, et que le probl`eme global n’est ici pas contraint, pourquoi se fait-il que la solution optimale ne soit pas trouv´ee imm´ediatement dans tous les cas ? La raison est tout simplement que la r´esolution partielle n’interdit pas, `a l’inverse du mod`ele logique du probl`eme global, de repasser par un mˆeme nœud. Dans le cas o`u une r´esolution est guid´ee par une solution partielle repassant par un mˆeme nœud, le guidage devient incomplet et par cons´equent faillible.

3.3.3 Conclusion

En conclusion, l’approche de colonies de fourmis n’am´eliore pas drastiquement les perfor- mances face `a l’approche de plus court chemin, cette derni`ere s’av´erant relativement efficace sur les instances utilis´ees. En revanche, elle permet d’obtenir des temps d’obtention de la solution optimale plus contenus. Cette approche est ainsi plus stable face aux modifications struc- turelles du probl`eme. En effet, ces r´esultats nous montrent qu’une modification mineure du probl`eme peut modifier totalement les performances du solveur. Le meilleur exemple est celui de la m´ethode sans guidage, extrˆemement performante sur la 3e

instance, et tr`es m´ediocre sur les deux autres. Pourtant, les graphes des trois instances ne pr´esentent pas de diff´erence importante (voir annexe). La stabilit´e de l’approche de colonies de fourmis est coh´erente avec le cadre applicatif des travaux, car elle renforce le caract`ere anytime de l’approche (en offrant davantage de garanties sur la qualit´e de la solution en cas de besoin imm´ediat).

Si les r´esultats des essais r´ealis´es montrent une bonne efficacit´e de l’approche SP, c’est parce qu’elle reste appliqu´ee `a des instances de petite taille. Sur des probl`emes plus grands, la m´ethode est bien moins performante d`es lors que les points de passage obligatoires sont situ´es « loin » de la solution partielle (qui est plus ou moins un axe vs–vg en g´en´eral). C’est l`a que l’approche

ANTS prend tout son sens, car elle va pouvoir r´ealiser un guidage efficace vers chacun des points obligatoires. Pour d´emontrer ces propos, nous avons ´elabor´e une quatri`eme instance de test, de plus grande taille cette fois. Le graphe comporte ici 33 nœuds et 130 arcs. Les jeux de configurations et une illustration du graphe sont fournis en annexe 5.3.4. L’instance ´etant de taille plus importante, un d´elai d’expiration de la recherche (timeout) a ´et´e mis en place et fix´e `a 30 secondes. La figure 3.16 pr´esente les r´esultats comparatifs des approches SP et ANTS en termes de temps d’obtention d’une solution (la meilleure dans le d´elai imparti, et donc pas n´ecessairement optimale).

Les r´esultats montrent ici un net avantage pour l’approche ANTS, dont les temps d’obtention moyens de solutions sont bien plus faibles. De plus, ces temps comportent un nombre plus important de solutions optimales que la m´ethodes SP. Ainsi, sur 50 configurations diff´erentes,

Figure _{3.16 – HAUT : Temps de calcul moyens (histogrammes) et maximum (barres} d’erreur) d’obtention de la meilleure solution (pas n´ecessairement optimale !) pour les approches SP (guidage par plus court chemin simple) et ANTS (guidage par colonies de fourmis) sur l’instance 4. Les temps sont donn´es en millisecondes. BAS : Nombre de cas o`u la solution optimale n’a pas ´et´e trouv´ee apr`es 30 secondes (d´elai d’expiration de la recherche), pour chaque jeu de configurations.

ANTS ´echoue `a 4 reprises pour trouver la solution optimale dans le temps imparti, tandis que SP ´echoue `a 32 reprises.