Dans ce chapitre, nous proposons un nouveau schéma de parallélisation basé sur la constatation que les processus simulés ne modifiant que leur état local, ils sont intrin-sèquement parallèles. Notre approche est donc de garder la simulation séquentielle, mais de paralléliser l’exécution des processus utilisateurs. L’avantage majeur de cee approche est qu’elle évite complètement le problème classique de la simulation parallèle, à savoir le maintien de la cohérence entre les évolutions temporelles réalisées par chaque élément de la simulation. Au lieu de cela, une seule évolution temporelle est utilisée, en exploitant le parallélisme potentiel existant en son sein.
L’algorithme de simulation utilisé dans SimGrid avant les travaux présentés ici est rappelé page 115. L’idée centrale est que le temps simulé n’avance que lors des appels
au noyau de simulation en ligne 6. Cela signifie que toutes les actions effectuées par U1
et U2 se déroulent à l’exact même instant simulé, et qu’il n’y a donc aucune différence observable selon l’ordre dans lequel ces actions sont calculées. D’un point de vue formel, toutes les transitions de Ptimesont parfaitement concurrentes. Il n’y a donc aucun risque d’exécution désordonnée de ces actions, qui peuvent donc être exécutées en parallèle. Le nouvel algorithme de simulation est présenté page116. La seule différence est que les processus simulés sont exécutés en parallèle, et le reste de l’algorithme reste inchangé par ailleurs. Il convient bien entendu, de noter que ceci n’est rendu possible que par le travail de refactoring présenté au chapitre 2. Il assure en effet que l’état partagé n’est pas modifié directement par les contextes d’exécution des processus utilisateurs, mais uniquement par le maestro de la simulation lors du traitement des requêtes posées par les processus.
En ce qui concerne l’implémentation de ce schéma de parallélisation, plusieurs choix s’offrent à nous. Comme nous l’avons vu précédemment, SimGrid exécute chaque proces-sus simulé au sein d’un contexte d’exécution ucontext, tel que standardisé par POSIX. Ce mécanisme peut être vu comme une extension de setjump et longjmp permeant de sauvegarder la pile système en plus des registres du processeur. Une première ap-proche pour permere l’exécution parallèle de ces contextes est de les faire évoluer en des threads à proprement parlé, mais ce n’est pas adapté à notre contexte pour plusieurs raisons. Tout d’abord, le nombre de threads que les systèmes d’exploitation actuels est de l’ordre de quelques dizaines de milliers là où nous visons des simulations de plusieurs millions de processus. De plus, même lorsque cee limitation n’est pas aeinte, cee implémentation reste inefficace car le nombre d’entité de calcul du processeur est bien inférieur au nombre de contextes à exécuter. Le système d’exploitation doit alors gérer la contention de ressources entre les contextes, au moyen de changements de contextes inutiles.
Une approche plus intéressante consiste à utiliser autant de threads que d’unités de calcul dans la machine, et à répartir les différents contextes à exécuter entre eux, comme représenté dans la figure 4.2b, page 116. De cee façon, aucune contention entre les threads système n’est à craindre tout en permeant une exécution parallèle. L’implé-mentation est plus complexe que dans le cas précédent, mais reste possible en combi-nant des threads classiques et des ucontext, qui permeent de manipuler les contextes d’exécution comme des valeurs du premier ordre à la façon des continuations. La figure
contextes utilisateurs U1, . . ., U4. La charge de travail est répartie entre les threads tout en limitant au maximum les besoins de synchronisation entre eux.
Analyse des coûts de la simulation. Il est courant de penser que la parallélisation
con-stitue une panacée pour les performances en temps. La simulation concon-stitue cependant un problème intrinsèquement séquentiel, et il est donc primordial de comprendre les dif-férents coûts en jeu afin de comprendre les compromis réalisés lors de l’implémentation, ainsi que pour prédire les scénarios dans lesquels le parallélisme est le plus promeeur. La figure 4.4(page118) présente une répartition temporelle de l’exécution séquentielle et de l’exécution parallèle. Le nombre d’itération de la simulation reste inchangé après parallélisation, ainsi que les coûts dus au noyau de simulation SURF ou à la couche de virtualisation SIMIX. La différence apparaît au niveau de l’exécution des processus util-isateur (dont le temps passe de la somme de chacun d’entre eux au max des sous-sommes correspondantes à chaque thread worker), et aux coûts de syncronisation entre threads worker naturellement absents dans la version séquentielle. Cela permet de déduire sim-plement les scénarios où la parallélisation va s’avérer bénéfique : il s’agit des cas où les coûts de synchronisation entre threads vont être compensés par les gains résultant de l’exécution parallèle.
La taille du code utilisateur a donc un impact primordial sur les bénéfices potentiels de cee approche. Dans une simulation composée de peu de processus effectuant des calculs relativement lourds (comme c’est aendu en HPC), la parallélisation sera trivialement gagnante tandis que dans une simulation composée d’un très grand nombres de processus effectuant des calculs simples (comme aendu en P2P), il sera très difficile d’amortir les coûts du parallélisme grâce aux gains ainsi obtenus.
Une autre façon de favoriser le parallélisme est de jouer sur la précision numérique de la simulation¹. Comme le temps est discrétisé dans une simulation à événements discrets, la précision numérique indique le nombre de timestamp existant sur un inter-valle de temps. Si le nombre de processus vient à grandir énormément, il est aendu que les événements soient répartis sur moins d’étapes de simulation quand la précision numérique décroît (puisque la quantité de timestamp possibles décroît). Les coûts de synchronisation seront donc rentabilisés plus facilement par la plus grande abondance 1. Le lien entre réalisme de la simulation et précision numérique utilisée pour les calculs est moins important qu’on pourrait le penser à première vue. En effet, les modèles utilisés pour la simulation se révèlent en général relativement stable numériquement. Le réalisme dépend donc plutôt du modèle utilisé et de la finesse de la modélisation résultante que de la seule précision numérique
de parallélisme potentiel à chaque étape de simulation.