Comment mesurer un benchmark MPI par nœud en utilisant le code source?

Question

Je me demande comment il est possible de mesurer la bande passante de la mémoire (Stream benchmark) PER NODE. Ce programme que j'ai, mesure sur un seul noeud, le nombre de processus et les discussions seront prises comme suit:

MPI_Comm_size(MPI_COMM_WORLD, &numranks); 
MPI_Comm_rank(MPI_COMM_WORLD, &myrank); 
omp_set_dynamic(0);  
omp_set_num_threads(4); 
#pragma omp parallel 
{ 
} 

Il est en fait un mélange de mpi et OpenMP. Est-il possible de spécifier le nœud et de faire les mesures pour chaque nœud? (supposons que j'ai 4 nœuds) Je voudrais le faire en utilisant le code source PAS le script slurm-batch. Je peux spécifier le premier noyau de chaque nœud en utilisant l'ID de processus mais comment exécuterait-il les mesures sur l'ensemble du nœud à chaque fois (inclure un nombre quelconque de cœurs)?

Toute suggestion serait appréciée.

Answer 1

Cela fait un moment que j'ai utilisé MPI, donc je ne réponds pas vraiment à la question «comment écrire le code». Je me concentre davantage sur le côté de la méthodologie de référence, donc j'espère que vous pouvez le concevoir pour mesurer quelque chose d'utile. L'analyse comparative est difficile. Il est facile d'obtenir un nombre, difficile d'obtenir un significatif nombre qui mesure ce que vous vouliez mesurer.

---

au lieu de spécifier quels nœuds vous obtenez, vous pouvez simplement interroger quels nœuds vous avez . (ie détecter le cas où plusieurs processus de votre travail MPI ont fini sur le même hôte physique, en compétition pour la bande passante mémoire.)

Vous pouvez également randomiser combien de threads vous exécutez sur chaque nœud, ou quelque chose, pour voir comment la bande passante échelles avec le nombre de threads faisant un memcpy, memset, ou quelque chose en lecture seule comme une réduction ou memcmp.

---

Un fil par machine ne sera pas se rapprocher de saturant bande passante mémoire, sur récente Intel Xeon, sauf peut-être pour les CPU-faible nombre-core qui sont semblables aux CPU de bureau. (Et puis seulement si votre code compile efficacement asm vectorisé). La latence L3/mémoire est trop élevée pour que le parallélisme limité de la mémoire d'un seul cœur sature le débit. (Voir Why is Skylake so much better than Broadwell-E for single-threaded memory throughput?, et « temps de latence lié à des plates-formes » dans Enhanced REP MOVSB for memcpy.)

Il peut prendre 4 à 8 fils en cours d'exécution du code à largeur de bande goulot d'étranglement (comme un indice de référence STREAMS) pour saturer la largeur de bande de mémoire d'un Xeon nombreux conducteurs. Plus de threads que celui-ci aura à peu près le même total, à moins que vous ne testiez avec des baies assez petites pour que le cache L2 privé par cœur entre en jeu. (256kB sur les processeurs Intel modernes, par rapport à la grande ~ 2MB partagée par L3 core). Mise à jour: 1 Mo par core L2 privé sur Skylake-AVX512.

Avec les nœuds à deux sockets, NUMA est un facteur. Si vos threads finissent par utiliser de la mémoire qui correspond aux contrôleurs de mémoire physique sur une socket, laissant les contrôleurs de mémoire de l'autre socket inactifs, vous ne verrez que la moitié de la bande passante de la machine. Cela peut être un bon moyen de vérifier que l'allocation de mémoire physique compatible NUMA de votre noyau fait un bon travail pour votre charge de travail réelle. Gardez à l'esprit que la bande passante de la mémoire est une ressource partagée pour tous les cœurs d'un nœud. Par conséquent, pour des résultats reproductibles, vous devez éviter de concurrencer les autres charges. Même si une petite empreinte mémoire peut utiliser beaucoup de bande passante, si son jeu de travail ne correspond pas aux caches privés L2 par cœur, ne supposez donc pas qu'un autre travail ne sera pas en concurrence pour la bande passante mémoire uniquement parce qu'il utilise uniquement quelques centaines de MB.