Optimisations

Nous allons determiner les sources des appels inutiles a ^Tell et, dans certains cas, denir des optimisations pour les eviter. L'impact de celles-ci sera evalue en pourcentage de^Tells (totaux et inutiles) evites et en pourcentage de temps d'execution economise. La premiere mesure est interessante parce que independante de la machine donc generale. La seconde mesure permet toutefois de se faire une idee de l'impact d'une optimisation sur le temps de calcul.

Equivalence de contraintes

Le fait d'ecrire plusieurs contraintes ^{X in r} pour une m^eme contrainte de haut niveau a pour consequence que ces contraintes sont souvent equivalentes et donnent lieu a des appels inutiles.

Considerons la contrainte ^X = ^Y + 5, ('x=y+c'(X,Y,5), cf. exemple 2.1) dans le ^store courant :

fX in 5..15, ^{Y in 0..10g} donnant :

fX in 5..15, ^{Y in 0..10},

X in min(Y)+5..max(Y)+5 (C^X),

Y in min(X)-5..max(X)-5 (C^Y)^g

Que se passe-t-il lors de l'ajout de la contrainte X in 12..100 ? X est initialise a 12::15 donc son min est propage a Y via C^Y (^{Y in 7..10}). Or, du fait que le min de Y a ete modie, C^X (X in 12..15) sera reexecute inutilement (i.e. le Tell ne modie pas le domaine de X). Evidemment, il est inutile d'evaluer a nouveau X a partir de Y puisque Y vient juste d'^etre evalue a partir de X et que C^X etC^Y sont equivalents.

Optimisation 1 :

lors de l'ajout de la contrainte c, il est inutile de reexecuter c⁰ sic⁰ est equivalent a c.

Dans la premiere version de ^clp(FD) (cf. [24]), cette optimisation etait implantee. Il n'y avait pas a proprement parler de detection des contraintes equivalentes mais plut^ot un imperatif pour l'utilisateur : toutes les contraintes denies dans une m^eme clause devaient

^etre equivalentes. Du fait que toutes ces contraintes se partageaient le m^eme environne- ment (pointe par ^AF) le test d'equivalence revenait a tester l'adresse des environnements necessaires aux contraintes impliquees. L'economie realisee etait de l'ordre de 18 % deTell representant 12 % du temps d'execution dans le meilleur des cas (equations lineaires) mais etait nulle dans le pire des cas (ex. ^queens).

Cette optimisation a ete abandonnee dans la version actuelle de^clp(FD)car d'une part son gain en temps d'execution est marginal et d'autre part elle est soumise a des conditions assez fortes (ex. inutilisable avec des divisions a cause des arrondis) et/ou diciles a contr^oler (ex. equivalence des contraintes ecrites par l'utilisateur). Enn, la le de propagation devait contenir des triplets de la forme <variable X, ^AF, listes a reactiver> pour permettre de reactiver les listes (indiquees) de contraintes dependant de X en testant l'adresse des environnements pour detecter l'equivalence. De ce fait, plusieurs triplets pour la m^eme variable (avec des pointeurs d'environnements dierents) pouvaient appara^tre dans la le.

La suppression de cette optimisation nous permet desormais d'utiliser une le dont les elements sont des couples de la forme <variable, listes a reactiver>. Il est aise d'assurer qu'il y a au plus un seul couple pour toute variableX (en regroupant les listes a reactiver en presence de plusieurs couples pour une m^eme variable). De ce fait, la taille de notre le de propagation est bornee par le nombre de variables. Il est alors possible de representer cette

Chain_Val Chain_Dom Chain_Min_Max Chain_Max Chain_Min Chains_Mask Chains_Stamp Vector Max Min Extra_Cstr Nb_Elem Range_Stamp Q_Next_Fdv_Adr Q_Propag_Mask Q_Date_At_Push FDV

variable DF Informations

sur le domaine

Informations file de propag.

Informations de dependances

Listes de contraintes dependant de la variable

Domaine

Masque listes non vides Estampille pour trail

Nombre d’elements du domaine Estampille pour trail

Ptr prochaine var. en file Masque listes a reexecuter Date derniere mise en file

Figure 12 : nouvelle representation interne d'une variable DF

le directement au travers des variables DF. La le ne necessite plus d'allocation explicite de memoire gr^ace a un cha^nage des variables. Lorsqu'une variable DF est modiee elle est juste cha^nee aux autres variables dont certaines contraintes doivent ^etre reactivees. Deux cas peuvent alors se produire :

la variable est deja cha^nee, il sut de mettre a jour la liste des contraintes a reveiller.

la variable n'est pas encore cha^nee, il sut de la cha^ner.

Notons que ce procede evite des mises en le multiples d'une m^eme variable donc de m^emes contraintes (cf. optimisation 3). Le moyen le plus ecace de tester si une variable est cha^nee consiste a dater toute mise en le. Un registre ^DATE est alors ajoute et est incremente a chaque appel de plus haut niveau d'une contrainte (i.e. par ^{fd call constraint} et non pas a chaque appel issu de la propagation). Ainsi, une variable ^X est cha^nee si

Date At Push(^X) = ^DATE. La representation interne d'une variable est donc etendue pour prendre en compte les informations de cha^nage (cf. gure 12). Les registres ^BP et^TP sont toujours utilises mais pointent desormais la premiere et la derniere variable DF de la le.

Impact :

la table 13 presente les gains de cette nouvelle organisation (cf. table 14 pour plus d'informations). La diminution moyenne de 5 % sur le nombre de ^Tells inutiles est

due aux re-executions evitees et sera expliquee lors de la presentation de l'optimisation 3.

Le benece moyen de 16 % sur le temps d'execution est en grande partie (environ 10 %) d^u aux simplications de certaines operations inherentes a la nouvelle le.

nb. de ^Tells Temps total inutile exec.

Pire (^{queens 70 ff}) 0 % 0 % 12 %

Moyen 4 % 5 % 16 %

Meilleur (^{alpha ff}) 13 % 16 % 25 % Tableau 13 : gain de la le optimisee

File optimisee Decomposition des^Tells

Temps ^Tell Reduc Verif Verif Echec Echec

Programme exec. (nombre) domaine domaine entier entier domaine

crypta 0.080 8302 2074 3754 2422 11 41

eq10 0.090 14341 2995 7792 3505 8 41

eq20 0.140 22059 5026 11164 5820 13 36

alpha 8.030 871838 254938 324838 283622 3817 4623

alpha ff 0.120 13176 2762 6392 4005 13 4

queens 16 1.390 64619 21132 6954 34700 834 999

queens 64 ff 0.170 4556 1813 276 2446 2 1

queens 70 ff 41.970 2009404 171859 81159 1747810 5387 3189

queens 81 ff 0.340 10633 3004 609 7011 6 3

five 0.010 558 225 52 267 14 0

cars 0.040 2439 402 1265 772 0 0

Tableau 14 : decomposition des ^Tells avec une le optimisee

Satisfaction de contraintes

Une autre source d'appels inutiles a ^Tell est due aux contraintes satisfaites qu'il est alors inutile de remettre en cause. Considerons par exemple la contrainte^{X 6}=^Y (^'x6=^y'(X,Y)) dans le ^store :

fX in 1..10, ^{Y in 1..10g} donnant :

fX in 1..10, ^{Y in 1..10},

( ^X),

Y in -fval(X)g (^CY)^g

Quand^X est initialise a 5, ^CY est reveille et 5 est supprime du domaine de ^Y fournissant le ^store suivant :

fX=5, ^{Y in 1..4:6..10}, ^CX,^CYg

Supposons alors que la contrainte ^Y=8 soit ajoutee. Apres modication du domaine de

Y, la phase de propagation re-executera ^CX veriant inutilement que 5 ⁶= 8. En eet, la contrainte ^CX est desormais satisfaite puisque 5 n'appartient plus au domaine de ^Y. Du fait qu'un resolveur sur les DF base sur la propagation locale n'est pas complet, il ne serait pas realiste de vouloir detecter \au plus juste" la satisfaction d'une contrainte. Ceci entra^nerait souvent l'enumeration des variables a chaque^Tell. Ainsi, la meilleure maniere de faire consiste a utiliser une approximation de la condition de satisfaction. Au chapitre 6 nous detaillerons ce principe. Pour l'instant, considerons que la seule approximation (i.e.

condition susante) pour detecter la satisfaction d'une contrainte ^{X in r} est un test de cl^oture sur ^X, i.e. si ^X est clos dans ^S alors ^S satisfait ^{X in r}. Ainsi, dans l'exemple precedent, quand la contrainte^Y=8est ajoutee,^{X in -fval(Y)g} est detectee comme etant satisfaite car ^X est clos. Evidemment, ceci n'est vrai que si ^X est devenu clos ^avant (et non pas ^pendant) la phase de propagation courante (i.e. toutes les propagations dues a la reduction de ^X doivent avoir ete eectuees).

No documento pour obtenir le grade de (páginas 111-115)