Vers un système réflexif

Si la spécification d’une fonction de coût associée à la recherche des solutions d’un problème permet d’orienter cette recherche, la PPC propose de plus l’accès à des fonc- tionnalités liées à son principe de fonctionnement, c’est-à-dire le parcours d’un arbre de recherche.

En particulier, la résolution d’un problème générique ne peut être résolue efficace- ment avec une stratégie générique. Il faut donc adapter les mécanismes de résolution d’un problème à ce dernier, c’est-à-dire permettre au développeur de vues de modifier depuis celles-ci le fonctionnement du solveur.

Réduction de la fonction de coût

Une fonction de coût spécifie un objectif à atteindre lors de la résolution d’un problème, sa sémantique se place donc non pas dans le cadre du centre considéré mais uniquement dans le cadre d’une recherche de solution. En cela la sélection de cette fonction est une forme de réflexion. Nous poussons plus loin cette fonctionnalité en permettant de paramétrer l’intégration de cette fonction de coût au problème.

En effet lorsque les modèles considérés sont imprécis, deux solutions dont la dif- férence de coût est de l’ordre de cette précision peuvent être considérées comme équi-

70 CHAPITRE 4. OPTIPLACE valentes. Par exemple, si la fonction de coût est précise à 20% près, alors une solution dont le coût est 100 et une solution de coût 90 peuvent être considérées équivalentes dans l’arbre de recherche. Quand une solution est trouvée par le solveur, la recherche des solutions équivalentes à une précision près n’est plus intéressante. Il est alors pos- sible d’élaguer l’arbre de recherche en éliminant au plus tôt les solutions dont le coût est équivalent.

Notre approche permet de spécifier une fonction de réduction du coût. Dans notre exemple précédent, dès que l’exploration d’un arbre obtient une solution dont le coût vaut 200, cette fonction de réduction est alors appelée. Elle indique au solveur que celui- ci doit désormais chercher des solutions dont le coût est inférieur à 100−20₁₀₀ × 200 = 160. Cette fonction de réduction réduit ici le coût d’une solution trouvée de 200 à 160.

Cette réduction considère dans notre exemple une précision relative et consiste en un simple multiplicateur de coût. Un développeur peut cependant spécifier des réductions de coût plus complexes, par exemple une homothétie centrée en _1−αβ et de coefficient α de formule r(c) = α × c + β ou un déplacement absolu de vecteur δ de formule r(c) = c + δ. Ces trois représentations sont intégrées au cœur d’OPTIPLACEmais celui- ci permet à un développeur d’intégrer ses propres formules.

En pratique, l’utilisation de cette fonctionnalité réduit l’espace de recherche, mais seulement quand la la formulation du coût le permet. En effet, il n’est pas toujours pos- sible d”éliminer des branches de l’arbre des solution à partir de la fonction de coût. Cette possibilité dépend principalement de l’intégration de la fonction de coût au problème. Ainsi la réduction d’une fonction de coût très complexe n’a qu’un impact très réduit sur la recherche des solutions par le solveur.

Cette approche ne permet plus d’obtenir la meilleure solution, mais une solution satisfaisante, qui dans certains contextes tels la réduction énergétique est suffisante. Paramétrage de l’injection des règles

Le cœur d’OPTIPLACEne permet de déclarer qu’un seul type de contraintes : les contraintes de satisfaction des ressources, générées automatiquement à partir des spécifications d’utilisation des ressources serveur par les VM. Cette contrainte de packing des res- sources était au cœur d’ENTROPY. Bien que formellement très simple, elle peut être traduite de différentes manières dans un problème de PPC. Plus particulièrement, le comportement associé à la mise à jour des variables de la contrainte, aussi appelé pro- pagation de la contrainte, peut être adapté à différentes classes de problèmes.

La méthode d’injection de ce type de contrainte peut être spécifiée dans le cœur. Ainsi l’administrateur peut utiliser sur un problème à contraintes spécifiques une im- plémentation de packing à faible recherche d’optimisation. De la même manière il peut utiliser un algorithme plus intelligent pour un autre problème, qui analysera le système sous tous ses angles.

4.2. OPTIPLACE 71 le développeur de vues. En effet, les vues peuvent communiquer entre elles, puisqu’une vue peut être construite en s’appuyant sur les fonctionnalités d’une autre vue. Il est ainsi possible de fournir des vues fonctionnelles pures, c’est à dire ne fournissant que des fonctions de manipulation du problème sans altérer celui-ci par des données ou règles propres.

Ainsi des fonctionnalités de contraintes spécifiques, telles du calcul matriciel, peuvent être ajoutées à OPTIPLACE sans changer son noyau. Ces vues peuvent être échangées pour d’autres vues proposant les même fonctionnalité sans rompre la cohérence du pro- blème. Ces fonctionnalités peuvent être utilisées pour la génération de contraintes liées à une vue ou la création de stratégies de recherche associées à un problème.

Stratégies de recherche

Une adaptation usuelle d’un solveur de PPC au problème qu’il résout passe par la spé- cification d’une stratégie de recherche, ou heuristique. Dans un problème de PPC, une heuristique permet de choisir quelle branche traiter en priorité dans l’exploration de l’arbre de recherche. Elle est issue de l’expérience de résolution d’un problème et per- met d’ajouter à ce problème des connaissances qui ne peuvent être exprimées par la PPC.

Le solveur de PPC Choco, utilisé par le cœur d’OPTIPLACE, permet de définir de telles stratégies. Nous utilisons ses modèles pour permettre la création, à partir des élé- ments des vues, des heuristiques à utiliser lors de l’exploration de l’arbre des solutions. Elles peuvent être spécifiées par un développeur, ou indirectement par la fonction de coût associée au problème.

Le paramétrage direct par le développeur permet de comparer facilement les perfor- mances de stratégies proches, en résolvant deux fois le même problème avec ces deux stratégies successives.

Performances du solveur

L’effet des paramètres de résolution d’un problème peut être déduit des performances du solveur lors de la résolution d’un problème. Celles-ci sont mises à la disposition des développeurs après la résolution d’un problème, permettant de comparer facilement les paramétrages. Sont ainsi présentés les durées de création et résolution du problème, de même que les nombres de contraintes et variables crées par chaque vue ajoutée au problème. Ces valeurs permettent d’évaluer les compromis induits par les stratégies de recherche, par exemple celles que nous avons développées pour la vue énergétique. Elles permettent aussi de d’évaluer l’intégration commune de plusieurs vues.

S’il est vrai que les vues peuvent être mélangées dans OPTIPLACE, la PPC n’auto- risant qu’une fonction de coût pour un problème, il n’est possible de minimiser qu’une seule fonction de coût. Ceci peut poser problème pour prendre en compte plusieurs coûts

72 CHAPITRE 4. OPTIPLACE à réduire dans un même problème. Dans ce cas, il y a deux solution : ou bien créer une fonction de coût qui soit un amalgame des autres fonctions de coût, ou bien développer une vue définissant sa propre fonction de coût composite. Dans le deuxième cas, si la composabilité de la PPC assure un fonctionnement correct, il n’en est pas de même pour les performances du solveur.