Babel : Modes d'exécution des nœuds de calcul et positionnement des processus

Modes d'exécution des nœuds de calcul

Attention : le mode d'exécution utilisé a des conséquences importantes sur la comptabilité de vos travaux (voir les notes sur la comptabilité des travaux).

Chaque nœud de calcul peut fonctionner dans un des trois modes suivants :

SMP : un nœud de calcul (CN) est vu comme un nœud SMP quadriprocesseurs. Il n'y a alors qu'un seul processus MPI par CN, processus qui peut accéder au 2 Go de mémoire. Si on n'utilise pas de multithreading, seul un cœur physique est réellement utilisé sur les quatre que comporte le noeud. Pour utiliser les trois autres cœurs, il faut mettre en œuvre une parallélisation hybride de son application de type MPI entre les CN et OpenMP/Pthreads à l'intérieur du CN. Dans ce cas, on peut utiliser un maximum de 4 threads par processus MPI.
DUAL : un nœud de calcul est vu comme 2 SMP biprocesseurs. Il y a alors 2 processus MPI par CN, chacun ayant accès à 1 Go de mémoire. Si le code n'est pas multithreadé, seul 2 cœurs sont utilisés sur les quatre disponibles. Pour utiliser les deux autres cœurs, il faut mettre en œuvre une parallélisation hybride de son application avec 2 threads par processus MPI.
VN : un nœud de calcul est vu comme 4 monoprocesseurs indépendants, chacun n'ayant accès qu'à un quart de la mémoire disponible sur le CN. Le modèle de programmation est alors purement MPI (pas de possibilité de multithreading). Il y a alors 4 processus MPI par CN, chacun ayant accès à 512 Mo de mémoire.

Mode	Nombre de processus MPI/nœud	Mémoire max/processus MPI
VN	4	512Mo
DUAL	2	1Go
SMP	1	2Go

Le mode d'exécution est précisé lors de la soumission (voir la page pour l'interactif et pour le batch) via la directive mode.

mpirun -mode VN -np 256 -exe ./my_code

Taille de la partition d'exécution

Chaque travail est lancé dans une partition. Une partition est un ensemble de nœuds de calcul. A cause de l'architecture matérielle de la machine, une partition doit contenir un multiple de 64 nœuds de calcul (soit un multiple de 256 cœurs). Attention : seules certaines tailles de partitions sont autorisées : 64, 128, 256, 512, 1024, 2048, 4096, 6144, 8192 ou 10240. En cas de choix différent, le système tentera d'adapter cette valeur (mais sans garanties).

Sa taille est codée dans les travaux à l'aide de la directive LoadLeveler bg_size.

# @ bg_size = 64

Choix du nombre de processus MPI

Il faut aussi faire attention à la manière de coder le nombre de processus MPI dans la commande mpirun par rapport à la taille de la partition. Le nombre de processus MPI doit être spécifié dans la commande mpirun (option -np).

Le nombre de processus MPI ne doit pas dépasser les ressources disponibles dans la partition que vous avez alloué.

En mode SMP, le nombre de processus MPI ne doit pas dépasser le nombre de nœuds de calcul, en mode DUAL à deux fois ce nombre et en mode VN à quatre fois ce nombre. Il est possible d'utiliser un nombre de processus inférieur à ces valeurs mais les ressources gaspillées vous seront comptabilisées.

Exemple d'un travail en mode VN :

# @ shell            = /bin/bash
# @ job_type         = BLUEGENE
# @ job_name         = job_vn
# @ output           = $(job_name).$(jobid)
# @ error            = $(job_name).$(jobid)
# @ wall_clock_limit = 1:00:00
# @ bg_size          = 64
# @ queue

mpirun -mode VN -np 256 -exe ./my_code

Exemple d'un travail en mode DUAL :

# @ shell            = /bin/bash
# @ job_type         = BLUEGENE
# @ job_name         = job_dual
# @ output           = $(job_name).$(jobid)
# @ error            = $(job_name).$(jobid)
# @ wall_clock_limit = 1:00:00
# @ bg_size          = 64
# @ queue

mpirun -mode DUAL -np 128 -exe ./my_code

Exemple d'un travail en mode SMP :

# @ shell            = /bin/bash
# @ job_type         = BLUEGENE
# @ job_name         = job_smp
# @ output           = $(job_name).$(jobid)
# @ error            = $(job_name).$(jobid)
# @ wall_clock_limit = 1:00:00
# @ bg_size          = 64
# @ queue

mpirun -mode SMP -np 64 -exe ./my_code

Positionnement des processus MPI (mapping)

Le positionnement des processus MPI ou mapping des processus MPI sur les cœurs de la machine peut avoir une influence importante sur les performances des communications.

Le réseau de communication point-à-point de la Blue Gene/P est caractérisé par une topologie de type tore 3D. Cela signifie que chaque nœud de calcul est connecté directement à 6 voisins (deux dans chaque direction). Rappellons qu'il n'est possible d'avoir un vrai tore 3D sur la machine Blue Gene/P que si le nombre de nœuds de calcul utilisés est un multiple de 512 et que la directive LoadLeveler #@BG_CONNECTION=TORUS a été spécifiée (dans le cas contraire, la topologie réelle est généralement très proche d'un vrai tore 3D ses connections aux extrémités n'étant pas actives). Si toutes les communications point-à-point sur la machine ont lieu entre des processus voisins dans la topologie, il sera possible de s'approcher des performances maximales de ce réseau et ainsi d'obtenir des performances très élevées pour les communications et une très bonne extensibilité.

Si les communications ont lieu avec des processus lointains dans la topologie, les performances seront réduites car la latence augmentera mais également le trafic sur les liens entre chaque nœud de calcul (en effet un message devra traverser plusieurs liens pour aller jusqu'à son destinataire). Il faut donc essayer que les processus qui communiquent ensemble soient proches dans la topologie.

Les trois axes de la topologie sont nommés X, Y et Z. Une quatrième dimension, appellée T, existe et correspond aux différents cœurs à l'intérieur d'un nœud de calcul (le placement étant fait sur des processus MPI, cette dimension n'a pas de sens en mode SMP).

Par défaut, la numérotation des processus MPI est faite selon un mapping TXYZ. Cela signifie que les processus sont placés consécutivement en faisant varier la première coordonnée T et ensuite X, Y et Z. Le mapping conseillé est aussi TXYZ. Il devrait donner de bonnes performances pour la majorité des codes car les processus de rangs proches seront également plus proches physiquement.

Le choix du mapping se fait via l'option -mapfile de mpirun. Elle prend soit un mapping prédéfini de la forme TXYZ et toutes ses permutations (XYZT, TYZX,...) avec la dimension T en premier ou dernier, soit le nom d'un fichier de mapping. Un fichier de mapping doit contenir une ligne par processus MPI et chaque ligne doit donner les coordonnées du processus correspondant au numéro de la ligne dans la topologie (un entier par dimension X, Y, Z et T séparés par des espaces).

Exemple de soumission d'un travail avec un mapping TXYZ :

# @ shell            = /bin/bash
# @ job_type         = BLUEGENE
# @ job_name         = job_txyz
# @ output           = $(job_name).$(jobid)
# @ error            = $(job_name).$(jobid)
# @ wall_clock_limit = 1:00:00
# @ bg_size          = 64
# @ queue

mpirun -mode VN -np 256 -mapfile TXYZ -exe ./my_code

Particularité Blue Gene/P : `MPI_Dims_create`

Attention : sur Blue Gene/P, le sous-programme MPI_Dims_create ne se comporte pas de façon standard. La norme MPI n'est pas respectée et les dimensions retournées par le sous-programme peuvent être différentes de celles attendues pour les topologies 3D et 4D.

Par exemple :

integer,parameter    :: ndims = 3
integer,dimension(3) :: dims

dims(:) = 0

call MPI_Dims_create(nproc,ndims,dims,code)

Si ce code est exécuté sur 8 processus en mode VN et avec un placement TXYZ, on obtiendra dims = (4,2,1) et non pas dims = (2,2,2).

Les dimensions choisies par l'implémentation MPI de Babel sont telles qu'elles collent au mieux à l'architecture matérielle de la machine. Il est donc conseillé de se baser sur ces valeurs.

Si votre application à besoin que ce sous-programme respecte la norme MPI, il suffit de positionner la variable d'environnement DCMF_TOPOLOGY à 0.

Exemple de commande à lancer pour forcer le respect de la norme MPI :

mpirun -env DCMF_TOPOLOGY=0 -mode VN -mapfile TXYZ -np 256 -exe ./my_application