Comme il a ´et´e dit dans la section 3.1, Simple a ´et´e cr´e´ee avec l’objectif de traiter un grand nombre de composants en parall`ele et un grand nombre d’´ev´enements. Pour ex´ecuter efficacement un grand nombre d’´ev´enements, Simple utilise le mˆeme m´ecanisme que l’on trouve dans les syst`emes d’exploitation, c’est-`a-dire, l’attente passive2. Dans cette section on va pr´esenter trois tests que l’on a con¸cus pour analyser les diff´erents types d’attente que l’on a identifi´es dans l’approche r´eactive.
Dans l’approche r´eactive, on peut parler de deux types d’attentes : l’attente inter-instant et l’attente intra-instant. L’attente intra-instant est g´en´er´ee par l’utilisation du drapeau SUSP ; ce drapeau sert `a suspendre l’ex´ecution d’une instruction, lorsqu’on n’a pas toute l’information pour l’ex´ecuter, pour pouvoir activer d’autres branches qui ´eventuellement permettront de continuer. Le probl`eme du drapeau SUSP est qu’il ne distingue pas les instructions suspendues qui doivent forcement ˆetre ex´ecut´ees dans l’instant (comme l’instruction When) de celles que l’on pourrait laisser endormies (comme l’instruction Wait). L’instruction Wait devrait en effet attendre passivement entre les instants jusqu’`a la satisfaction de sa configuration ; Wait pourrait d’ailleurs ´
egalement attendre passivement durant le premier instant (comme le fait Storm, grˆace au drapeau WAIT) ce qui serait utile dans certains cas comme, par exemple, la cascade inverse. L’attente intra-instant est analys´ee dans la section suivante.
L’id´eal serait d’avoir une impl´ementation qui ex´ecute une premi`ere fois les instructions ´ev´enementielles pour les identifier, et puis de ne plus les r´e-ex´ecuter que lorsque toutes les conditions n´ecessaires `a leur reprise sont r´eunies (durant l’instant de la premi`ere activation ou apr`es). L’´evolution des impl´ementations de Junior qui formalisent ces deux types d’attente a commenc´e par la formalisation de l’attente intra-instant (Storm) puis par celle de l’attente inter-instant (Glouton).
1er Programme de test
Pour d´eterminer qui impl´emente le plus efficacement l’attente inter-instant et voir l’´ecart existant avec les impl´ementations qui font de l’attente active, on a construit un programme qui met en parall`ele 1000 branches qui attendent l’´ev´enement i (i variant de un `a mille). Voici le programme utilis´e :
J r . Par ( J r e . Await ( 1 ) , J r . Par ( // b r a n c h 1
J r e . Await ( 2 ) , J r . Par ( // b r a n c h 2
. . .
J r e . Await ( 1 0 0 0 ) ) ) // b r a n c h 1 0 0 0
)
L’´ev´enement i n’est jamais g´en´er´e et le programme est ex´ecut´e durant N instants. R´esultats
Les figures 4.6 et 4.10 montrent le temps d’ex´ecution du programme (l’axe X repr´esente N ). Ces graphes corroborent que : 1) L’attente active inter-instant est impl´ement´ee par Rewrite, Replace et Storm ; Loft semble impl´ementer aussi une attente active mais de fa¸con tr`es efficace, 2) L’attente passive inter-instant est impl´ement´ee par Simple et Glouton.
2`eme programme de test
Une autre fa¸con de programmer l’attente en Junior est d’attendre l’absence d’un ´ev´enement. Pour analyser le comportement d’un programme r´eactif qui r´eagit `a l’absence d’un ´ev´enement qui est g´en´er´e `a chaque instant, on a construit un programme similaire au pr´ec´edent, mettant en parall`ele 1000 branches qui attendent l’absence d’un ´ev´enement i (i variant de un `a mille). Voici le programme utilis´e que l’on a ex´ecut´e pendant N instants : i n t i =0;
J r . Par ( J r e . Repeat ( 4 ,
J r . Seq ( J r . Atom { i ++; } , J r . Seq ( J r e . G e n e r a t e ( i ) ,
J r . Stop ( ) ) )
Fig. 4.6: L’attente inter-instant de la pr´esence.
) , J r . Par (
J r . Await ( J r . Not ( J r e . P r e s e n c e ( 1 ) ) ) , J r . Par ( // b r a n c h 1 J r . Await ( J r . Not ( J r e . P r e s e n c e ( 2 ) ) ) , J r . Par ( // b r a n c h 2 . . .
J r . Await ( J r . Not ( J r e . P r e s e n c e ( 1 0 0 0 ) ) ) ) ) ) // b r a n c h 1 0 0 0 )
R´esultats
La figure 4.7 montre le temps d’ex´ecution du programme. Ce graphe montre que la r´eaction `a l’absence est plus coˆuteuse que la r´eaction `a la pr´esence car : 1) Les impl´ementations comme Simple ou Glouton qui faisaient de l’attente passive font maintenant de l’attente active, 2) les impl´ementations qui faisaient de l’attente active ont vu leur temps augmenter : Jr-replace a augment´e d’approximativement 10 secondes lorsqu’on l’a ex´ecut´e 5000 instants (noter qu’il y a eu un changement d’´echelle, de 1000 `a 5000). Les impl´ementations qui parcourent toujours toutes les branches `a la fin de l’instant (comme Loft et Cr-replace ) ont les meilleurs temps d’ex´ecution. Comme d’habitude, les impl´ementations de Rewrite (en C ou Java) sont plus lentes que celles de Replace. Le seul comportement bizarre que l’on a observ´e est le temps d’ex´ecution de Glouton, beaucoup plus grand que Simple ; il apparaˆıt que la gestion de files en absence d’´ev´enement est tr`es ch`ere. Storm a aussi un temps d’ex´ecution tr`es grand mais diff´erent de celui de SugarCubes, ce qui nous fait penser `a un mauvais balancement de l’arbre du programme.
3`eme programme de test
Une des particularit´es de Junior est qu’il existe une instruction pour r´eagir `a la pr´esence d’un ´ev´enement `a chaque instant (instruction Control) mais qu’il n’existe pas d’instruction pour r´eagir `a l’absence d’un ´ev´enement `
a chaque instant (la r´eaction retard´ee d’un instant). Le programme suivant a ´et´e construit avec le but de voir le coˆut de la r´eaction `a l’absence `a chaque instant. Le programme attend l’absence d’un ´ev´enement i qui est g´en´er´e `a chaque instant. Voici la partie du programme qui r´eagit `a l’absence de i en ex´ecutant Stop :
J r . Par ( J r . Loop ( J r e . When( i ,
J r . Stop ( ) ,
J r e . G e n e r a t e ( i+” a b s ” ) ) ) , J r e . C o n t r o l ( i+” a b s ” ,
J r . Loop ( J r . Stop ( ) ) ) )
On a aussi construit un programme r´eactif qui r´eagit `a la pr´esence d’un ´ev´enement en boucle ; le programme que l’on a utilis´e est semblable au pr´ec´edent mais sans la premi`ere branche du Par.
R´esultats
Les figures4.8,4.9et4.11montrent les r´esultats de l’ex´ecution des programmes d´ecrits pr´ec´edemment pendant N instants (l’axe X). Ces graphes montrent que : 1) Il n’y a pas de diff´erence entre l’attente d’un ´ev´enement une seule fois (avec Await) ou N fois (avec Until), et 2) l’attente de l’absence d’un ´ev´enement est plus ch`ere lorsqu’on l’attend `a chaque instant. La r´eaction `a l’absence en boucle est plus ch`ere pour deux raisons : 1) les moteurs r´eactifs ont ´et´e con¸cus (et optimis´es) pour attendre la pr´esence et non l’absence (r´esultat corrobor´e dans les tests pr´ec´edents), et 2) la r´eaction `a l’absence `a chaque instant n´ecessite une structure particuli`ere (et non une seule instruction) ce qui rend l’ex´ecution plus lente. Dans les sections4.7et 4.8on montrera d’autres cas qui renforcent cette affirmation.
En conclusion, on peut dire qu’il vaut mieux cr´eer des syst`emes r´eactifs r´eagissant `a la pr´esence d’´ev´enements plutˆot qu’`a leur absence.
Fig. 4.8: L’attente inter-instant en boucle de la pr´esence.
Fig. 4.10: Agrandissement de la figure 4.6.