Initiation au cluster HPC@LR · inadvertance. Si le mot de passe est toujours refusé après de...

Initiation au cluster HPC@LR B. Leveugle

1

Initiation au cluster

HPC@LR

Version : 3.0

Date : lundi 10 novembre 2014

Auteur : Benoît Leveugle


2

Table des matières

1 Introduction .......................................................................................................................... 4

1.1 Comprendre un cluster .................................................................................................. 4

1.2 Ressources disponibles sur le cluster HPC@LR ........................................................... 5

2 Connexion au cluster ............................................................................................................ 6

2.1 Windows ....................................................................................................................... 6

2.2 Linux/Mac .................................................................................................................... 10

3 Découverte du shell ............................................................................................................ 12

3.1 Utilisation de Nano ...................................................................................................... 12

3.2 Utilisation de Vim ........................................................................................................ 13

4 Envoie et réception de fichiers............................................................................................ 14

4.1 Filezilla ........................................................................................................................ 14

4.2 SFTP ........................................................................................................................... 19

4.3 SCP ............................................................................................................................ 19

5 Espaces de stockage ......................................................................................................... 21

6 Utilisation des modules, compilation ................................................................................... 22

6.1 Compilation simple, Modules ....................................................................................... 22

6.2 Compilation avancée : optimisation ............................................................................. 25

6.3 Compilation avec OpenMP .......................................................................................... 26

6.4 Compilation avec MPI ................................................................................................. 26

7 Soumission de job .............................................................................................................. 28

7.1 Organisation d’un script de soumission ....................................................................... 29

7.2 Soumission de job pour une exécution sur plusieurs nodes : MPI ............................... 31

7.3 Exécution sur une node unique : OpenMP, Pthread .................................................... 33

7.3.1 Node Intel : ........................................................................................................... 34

7.3.2 Node SMP : .......................................................................................................... 35

7.4 Exécution sur une ou plusieurs nodes : GPU-CUDA ................................................... 37

8 Quelques conseils .............................................................................................................. 39

8.1 Performances : ............................................................................................................ 39

8.2 MPI : ........................................................................................................................... 39

8.3 OpenMP/Pthread :....................................................................................................... 39

8.4 Données : .................................................................................................................... 40

9 Annexe ............................................................................................................................... 41


3

9.1 Génération d’une clé de connexion permanente ......................................................... 41

9.2 Debug de base ............................................................................................................ 42

9.3 Notion de scaling ......................................................................................................... 43

9.3.1 Strong scaling ...................................................................................................... 43

9.3.2 Weak scaling ........................................................................................................ 45

9.4 Optimisation des calculs multithreads.......................................................................... 47


4

1 Introduction

Ce document vise à familiariser l'utilisateur à l'usage du cluster HPC@LR.

Y figurent les instructions pour :

se connecter au cluster

découvrir l'environnement du cluster

compiler un programme sur le cluster

exécuter le programme sur le cluster.

1.1 Comprendre un cluster

Vous allez utiliser pour la première fois un calculateur parallèle (cluster).

En premier lieu, il est essentiel de noter les différences entre une station de travail classique et

un cluster, ce afin de mieux appréhender les instructions qui vont suivre. Cette introduction se

repose sur la Figure 1 afin de faciliter la visualisation de l’architecture d’un cluster.

Figure 1 : architecture basique d’un cluster

Une station de travail (A) est généralement constituée d'un processeur (1), de mémoire vive

RAM (2) et d'une mémoire de stockage type disque dur (3). Un clavier, une souri et un écran

sont utilisés pour faciliter l'interface avec l'utilisateur, seul à utiliser la station à un instant donné.


5

Un cluster (B) tel HPC@LR peut être vu comme un regroupement de plusieurs stations de

travail évoluées et dédiées au calcul appelées "nodes". Chaque node possède 2 processeurs

(1), une importante quantité de mémoire vive (RAM) (2), et un accès par le réseau à un système

de stockage centralisé (4). Ce système de fichier "monté" sur chaque node assure que chaque

emplacement du cluster ait accès aux mêmes données que les autres (les données y sont

organisées comme sur un disque dur classique). Ces nodes sont "interconnectés" par un réseau

Infiniband à très haute performance (5). Il est à noter que certains clusters, comme HPC@LR,

possède des nodes particulières pour répondre à des besoins précis. Certaines dites à large

mémoire possèdent jusqu'à 8 processeurs (1) et leur mémoire vive (2) peut dépasser les 1 To.

D'autres sont équipées d'accélérateurs GPUs pour des calculs bien particuliers.

Le cluster est utilisé à distance par l'intermédiaire d'un terminal, via une connexion sécurisée de

type tunnel ssh. C'est à travers ce terminal que l'utilisateur donne des consignes au calculateur.

Un chef d'orchestre, le job scheduler, reçoit les requêtes de tous les utilisateurs et les répartie

au mieux sur les ressources disponibles.

1.2 Ressources disponibles sur le cluster HPC@LR

Le cluster dispose d’une node de login, 2xE5506, 24Go de Ram, utilisée conjointement par tous

les utilisateurs connectés. Elle fournit le shell de la connexion, permet les déplacements de

fichiers, permet la compilation des codes et toute autre opération disponible dans le terminal

utilisateur. Cette node peut être lente si de nombreux utilisateurs l'utilisent simultanément ou si

un utilisateur abuse des ressources collectives.

Le reste du cluster est composé de nodes dédiées au calcul :

88 nodes INTEL de type 2 sockets, 2 fois 6 cœurs (total de 12) cadencés à 2.66GHz. 24

Go de mémoire vive DDR3 1066 Mhz, 1 carte Infiniband 40 Gb/s.

6 nodes GPU de type 2 sockets, 2 fois 4 cœurs (total de 8) cadencés à 2.13GHz. 24 Go

de mémoire vive DDR3 1066 Mhz, 1 carte Infiniband 40 Gb/s, 2 cartes NVIDIA TESLA

M2050 (448 CUDA cores, 3 GB memory).

2 nodes SMP de type 8 sockets, 8 fois 10 cœurs (total de 80) cadencés à 2.27GHz. 1 To

(1000 Go) de mémoire vive, 1 carte Infiniband 40 Gb/s.


6

2 Connexion au cluster

La procédure de connexion ssh dépend du système d'exploitation de votre station de travail. A

noter que dans tous les cas, le tunnel ssh permet un échange sécurisé entre votre poste et le

cluster : tout ce qui y transite est chiffré. Il en va de même pour les méthodes d'envoi et de

récupération de fichier décrites un peu plus loin.

2.1 Windows

Il est nécessaire de télécharger un petit utilitaire appelé putty à cette adresse :

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Une fois l’utilitaire récupéré, l’exécuter. Renseigner ensuite le champ "Host Name" (Figure 2)

avec :

login.hpc-lr.univ-montp2.fr

Puis cliquer sur Open (Figure 2).

Figure 2


7

Le terminal s’ouvre. S’il s’agit de la première connexion, une fenêtre d’alerte s’ouvre (Figure 3).

Accepter l’alerte en cliquant sur Oui.

Figure 3

Une fois dans le terminal, renseigner l’identifiant (votre identifiant de connexion donné par

l’équipe HPC@LR) (Figure 4).


8

Figure 4

Valider (touche "Enter" du clavier), puis renseigner le mot de passe lié à l’identifiant (Figure 5).

Attention : lors de la saisie du mot de passe, rien ne s’affiche. Ce comportement est lié à des

raisons de sécurité, le système enregistre tout de même votre saisie.


9

Figure 5

Une fois le mot de passe renseigné, valider (touche "Enter" du clavier).

Si le système refuse le mot de passe, vérifier dans un autre endroit (autre terminal, fichier texte)

que la touche MAJ n'est pas activée ou que le système n'est pas passé en QWERTY par

inadvertance. Si le mot de passe est toujours refusé après de multiples essais, contacter le

support HPC@LR.

Si l’identifiant et le mot de passe ont bien été renseignés, la connexion s’établie (Figure 6) et il

est alors possible de lancer des commandes sur la node de login du cluster HPC@LR.


10

Figure 6

Important : dans la suite du document, le symbole ~$ en début de ligne symbolise la possibilité

de saisie de texte par l’utilisateur. Ne pas le recopier.

Il est maintenant temps de partir à la découverte du shell.

2.2 Linux/Mac

Linux et Mac partage le même ancêtre UNIX, la procédure est donc la même sur les deux

systèmes.

Sous Linux, le terminal se trouve dans le menu d’application. Sous Ubuntu, il est même possible

d’ouvrir un terminal en utilisant simultanément les touches "Ctrl+Alt+t" du clavier. Note : le

terminal peut aussi porter le nom de "console".

Sous Mac, le terminal se trouve dans Applications>Utilities>Terminal. Il est aussi possible de le

retrouver en saisissant "terminal" dans la zone de recherche.

Important : dans la suite du document, le symbole ~$ en début de ligne symbolise la possibilité

de saisie de texte par l’utilisateur. Ne pas le recopier.

Une fois le terminal ouvert, saisir la commande suivante en remplaçant "monlogin" par

l’identifiant qui vous a été communiqué par l’équipe HPC@LR pour la connexion au cluster :


11

S’il s'agit de la première connexion, le message suivant apparaitra :

Répondre yes à la question puis Valider (touche "Enter" du clavier). Note : si vous rencontrez à

nouveau ce message par la suite, la sécurité du tunnel ssh avec le cluster n’est alors peut être

plus assurée, contacter le support d’HPC@LR.

Le système demande ensuite le mot de passe associé à l’identifiant. Renseigner le mot de

passe puis valider (touche "Enter" du clavier).

Attention : lors de la saisie du mot de passe, rien ne s’affiche. Ce comportement est lié à des

raisons de sécurité, le système enregistre tout de même votre saisie.

Si le système refuse le mot de passe, vérifier dans un autre endroit (autre terminal, fichier texte)

que la touche MAJ n'est pas activée ou que le système n'est pas passé en QWERTY par

inadvertance. Si le mot de passe est toujours refusé après de multiples essais, contacter le

support HPC@LR.

Si l’identifiant et le mot de passe ont bien été renseignés, la connexion s’établie et il est alors

possible de lancer des commandes sur la node de login du cluster HPC@LR.

Il est maintenant temps de partir à la découverte du shell.

~$ ssh [email protected]

The authenticity of host 'login.hpc-lr.univ-montp2.fr (193.52.26.130)' can’t be established. RSA key fingerprint is 6f:f7:58:71:9e:4b:3d:e0:fa:fa:54:16:bd:bd:26:39. Are you sure you want to continue connecting (yes/no)?

~$ ssh [email protected] [email protected]’s password: Last login: Thu Sep 25 15:48:31 2014 from 193.48.168.162 ############################################### # # BIENVENUE SUR LE CLUSTER OCTANTIO DU CENTRE HPC@LR # # ############################################### - Support: https://www.hpctick.univ-montp2.fr Mail-> [email protected] [monlogin@login ~]$ echo 'Hello World !' Hello World ! [monlogin@login ~]$


12

3 Découverte du shell

L'environnement de travail qui s'affiche dans le terminal est appelé shell. Par défaut, le shell

utilisé est "bash". Il existe d'autres shells, mais l'utilisation de bash est recommandé, il s'agit de

l'environnement par défaut sur tous les systèmes Linux.

Il convient de se familiariser avec le shell pour profiter du plein potentiel du cluster HPC@LR.

Pour cela, il est fortement conseillé de prendre le temps de lire le tutoriel suivant :

Français : http://doc.ubuntu-fr.org/tutoriel/learn_unix_in_10_minutes

Anglais : http://freeengineer.org/learnUNIXin10minutes.html

Une autre difficulté couramment rencontrée sur un cluster est l’absence d’affichage graphique,

et donc d’éditeur de texte dans un format habituel. Il existe heureusement des éditeurs de texte

utilisable dans un terminal.

Pour les débutants, Nano est l’éditeur recommandé. Vim conviendra aux utilisateurs désireux de

pousser plus loin ou d’ouvrir des fichiers très volumineux.

3.1 Utilisation de Nano

Pour éditer un fichier texte appelé "exemple.dat", utiliser :

L'éditeur s'ouvre et se dirige avec les flèches du clavier pour la navigation dans le document.

Le symbole "^" représente la touche "Ctrl". Les consignes indiquées en bas du terminal sont

alors assez claires :

~$ nano -cw exemple.dat

GNU nano 2.0.9 File: exemple.dat Hello World ! [ line 1/2 (50%), col 1/14 (7%), char 0/14 (0%) ] ^G Get Help ^O WriteOut ^R Read File ^Y Prev Page ^K Cut Text ^C Cur Pos ^X Exit ^J Justify ^W Where Is ^V Next Page ^U UnCut Text ^T To Spell


13

Ctrl+G affiche l'aide, Ctrl+O écrit le fichier en cours (pour sauvegarder les modifications sans

fermer l'éditeur, l'équivalent "d'enregistrer sans quitter"), Ctrl+X permet de quitter l'éditeur.

Pour aller plus loin, les cours de l'openclassrooms sont complets et disponibles en ligne :

http://fr.openclassrooms.com/informatique/cours/reprenez-le-controle-a-l-aide-de-linux/nano-l-

editeur-de-texte-du-debutant

3.2 Utilisation de Vim

Présenter l'usage de Vim sort du cadre de ce document. Il est cependant possible d'apprendre

les bases à l'aide de la page suivante :

http://doc.ubuntu-fr.org/vim#principe_de_base

Si par inadvertance vous vous retrouvez bloqué dans Vim, utilisez la combinaison suivante pour

sortir de l'éditeur : Touche "Echap", touche ":", touche "q", touche "!", puis touche "Enter".

Pour aller plus loin, les cours de l'openclassrooms sont complets et disponibles en ligne :

http://fr.openclassrooms.com/informatique/cours/reprenez-le-controle-a-l-aide-de-linux/vim-l-

editeur-de-texte-du-programmeur

Maintenant que les fondamentaux du shell sont posés, il est temps d'envoyer des données

(code, data, etc) sur le cluster et d'en recevoir.


14

4 Envoie et réception de fichiers

4.1 Filezilla

Lors de l'envoie et de la réception de données, un tunnel ssh est utilisé, afin de sécuriser les

échanges. Le logiciel multiplateforme le plus à même d'envoyer/recevoir des données par ssh

est Filezilla. Filezilla est disponible à l'adresse suivante :

https://filezilla-project.org/download.php?show_all=1

Remarque : sous Linux, Filezilla est disponible par l'intermédiaire de votre gestionnaire de

paquets ("apt-get install filezilla" sous ubuntu, "yum install -y filezilla" sous redhat).

Une fois Filezilla installé, l'exécuter. L’interface (Figure 7) se compose de 5 grandes zones :

(1) La zone de connexion

(2) La zone d’informations générales

(3) La zone représentant les données sur la machine locale

(4) La zone représentant les données sur le cluster

(5) La zone d’information sur les données en cours de transfert


15

Figure 7

Pour établir la connexion (protocole sftp, basé sur ssh), rentrer les informations suivantes dans

la zone de connexion (1) :

Host : sftp://login.hpc-lr.univ-montp2.fr

Username : monlogin (remplacer par l’identifiant utilisé pour se connecter en ssh)

Password : (renseigner ici le password lié à l’identifiant)

Port : 22 (important, ne pas oublier)

Puis cliquer sur Quickconnect. S’il s’agit de la première utilisation de FileZilla, deux popups

apparaîtront. Un premier popup apparaitra (Figure 8) concernant le stockage des mots de

passe. Il est recommandé de choisir "Do not remember passwords".

(1)

(2)

(3) (4)

(5)


16

Figure 8

Un second popup concernant la clé de sécurité d’HPC@LR apparaitra (Figure 9). Cocher

"Always trust this host, add this key to the cache" afin de conserver la clé et d’être informé d’un

changement de clé lors d’une future connexion, ce qui signifierait un risque potentiel de sécurité

sur l’échange des données.

Figure 9

Une fois la connexion établie, il est possible de naviguer dans les répertoires de la machine

locale (3) et dans les répertoires du cluster (4). Pour envoyer un fichier local (zone (3)) dans le

répertoire ouvert sur le cluster (zone (4)), utiliser le clic droit dessus puis choisir "Upload" (ou

double cliquer sur le fichier) (Figure 10).


17

Figure 10

Le fichier est alors transféré vers le cluster et l’état de transfert est disponible sous forme de

texte dans la zone d’informations générales (2) et sous forme d’avancement dans la zone

d’information sur les données en cours de transfert (5). A l’inverse, pour récupérer un fichier sur

le cluster (Zone (4)) dans le répertoire ouvert sur la machine locale (zone (3)), utiliser le clic droit

dessus puis choisir "Download" (ou double cliquer sur le fichier) (Figure 11).


18

Figure 11

Note : si la connexion utilisée est lente (Wifi, 3G, etc.) et que les fichiers à envoyer sont de

petites tailles, il est recommandé de compresser l’ensemble de ces fichiers sous forme d’archive

avant de les envoyer sur le cluster ou de les recevoir. En effet, chaque transfert de fichier prend

du temps à démarrer, surtout sur les connexions lentes, et rassembler les fichiers sous une

seule archive augmente grandement la vitesse de transfert globale. Se reporter à la section

"Découverte du shell" et notamment au guide Unix en 10 minutes pour les commandes

permettant de créer des archives.

Outre Filezilla, il existe sous Linux et Mac d'autres moyens plus simples pour envoyer ou

recevoir des données sur un cluster.


19

4.2 SFTP

Dans un terminal, se placer dans le répertoire où se trouvent les données locales à envoyer sur

le cluster ou dans le répertoire où doivent être reçue les données en provenance du cluster, et

utiliser :

La méthode est semblable à la connexion ssh classique.

Après s’être connecté sur le cluster, il est possible de naviguer dans les répertoires avec les

commandes habituelles : cd, cd .., ls, etc.

Pour envoyer des données, utiliser la commande put, et pour récupérer des données, utiliser la

commande get. Par exemple, si sur la station de travail locale, dans le répertoire d'où a été

lancé la connexion sftp se trouve un fichier "file.txt", la commande put file.txt enverra ce fichier

sur le cluster à la position actuelle.

A noter cependant qu’il n’est pas possible d’envoyer ou recevoir un répertoire complet avec

SFTP, mais qu’il est possible d’envoyer plusieurs fichiers (ou recevoir) avec mput (mget).

4.3 SCP

Cette méthode a l'avantage d'être scriptable pour automatiser certaines tâches. De plus,

contrairement à SFTP, scp est apte à envoyer ou recevoir des répertoires complets. SCP

s’utilise en une seule commande qui indique la source et la destination. Si le fichier à transférer

est sur une machine distante (le cluster), la source comprendra l’adresse du serveur visé

accompagnée de l’identifiant de connexion, suivi du caractère ":" puis de la position exacte du

~$ sftp [email protected]

~$ sftp [email protected] [email protected] s password: Connected to login.hpc-lr.univ-montp2.fr. sftp> put file.txt Uploading file.txt to /gpfs2/data/home/monlogin/ file.txt file.txt 100% 5 0.0KB/s 00:00 sftp> get file.txt Fetching /gpfs2/data/home/monlogin/file.txt to file.txt /gpfs2/data/home/monlogin/file.txt 100% 5 0.0KB/s 00:00 sftp> exit ~$


20

fichier sur la machine distante. La destination sera la position voulue sur la machine locale. Si le

fichier à transférer se trouve sur la machine locale, il faut inverser cet ordre.

Par exemple, pour envoyer le fichier file.txt dans le home de l'utilisateur localuser vers le home

de l'utilisateur monlogin sur le cluster, utiliser :

Note : le -v active le mode verbose afin de visualiser l'avancement.

A l’inverse, pour récupérer ce fichier et le placer dans le répertoire /tmp de la station de travail

locale :

Pour récupérer un répertoire complet :

Important : à chaque utilisation d’SCP, le mot de passe lié à l’identifiant sera demandé. Dans le

cadre d’un script, il conviendra d’utiliser une clé publique pour que le système local puisse se

connecter au cluster sans passer par un mot de passe (Voir annexe).

Il est maintenant temps de découvrir les différents espaces de stockage présents sur le cluster.

~$ scp -v /home/localuser/file.txt [email protected]:/home/monlogin

~$ scp -v [email protected]:/home/monlogin/file.txt /tmp

~$ scp -vr [email protected]:/home/monlogin/rep /tmp


21

5 Espaces de stockage

Un cluster classique tel HPC@LR possède plusieurs espaces de stockages à utiliser en fonction

des besoins mais aussi des quotas.

Le /home est l'espace où l'utilisateur accède en premier après s'être logué. Le /home est un

espace dédié à stocker les données système (clés ssh, configurations, etc) ainsi que les

sources, les binaires des codes utilisés, et les données d’entrée ou sortie des codes de calcul. Il

est recommandé d’utiliser ce répertoire pour les codes sources.

Le /scratch est l'espace où ont lieux les calculs. La bonne pratique est d'y déposer les données

d'entrée liées au calcul visé, puis lors d'une soumission de job (vu après), l'utilisateur indique au

système de se placer dans le scratch pour y effectuer le calcul. Les données de sortie du

programme seront produites elles aussi dans le scratch. Le scratch est un espace performant

dédié au calcul et dont l’objectif premier est de ne pas ralentir les calculs par des temps de

lecture/écriture trop longs, les données ne doivent pas y résider plus de 2 mois sous peine de

suppression. Point important, le scratch n'est pas un espace sûr et son intégrité n’est pas

garantie : une fois le calcul effectué, il est conseillé de migrer les données vers le /home ou de

les rapatrier sur une station locale.

Le /work est l’espace accessible par l’ensemble des membres du groupe projet, afin d’échanger

ou de mutualiser des données. Il s’agit de l’espace à privilégier pour l’échange des données

d’entrée/sortie des codes ou pour la mutualisation des exécutables et des sources des codes du

groupe.

Le /home et le /work ont un quota cumulé de 50Go (/home + /work <= 50Go). Pour obtenir plus,

il est nécessaire de contacter l’équipe HPC@LR.

Il est maintenant temps de compiler le code avant d'effectuer des calculs.


22

6 Utilisation des modules, compilation

6.1 Compilation simple, Modules

Contrairement à une station de travail locale, de nombreuses versions de compilateurs et de

librairies sont présentes sur un cluster, chaque utilisateur ayant des besoins particuliers. Il est

donc nécessaire de passer par un système de modules pour laisser à l'utilisateur le choix du

compilateur utilisé. D'une manière générale, il est recommandé d'utiliser le compilateur

propriétaire Intel (icc pour gcc, ifort pour gfortran, icpc pour g++) si le code le permet : ses

performances sont souvent au-dessus de la suite GCC.

Les modules reposent sur un système de dépendances et de conflit fixés par la personne ayant

installé ou compilé le logiciel ou la librairie visée. Par exemple, l'utilisation d'un programme

compilé avec le compilateur Intel va nécessiter certaines librairies spécifiques à ce dernier pour

fonctionner. Le système de module réclamera que soit chargé le compilateur Intel avant que

puisse être chargé le module de ce programme. Le système refusera aussi le chargement de

certains modules qui rentreraient en conflit avec ceux déjà chargés. Il s'agit avant tout de

faciliter l'usage du cluster aux utilisateurs et d'éviter certains bugs liés aux versions de librairies.

Tous les modules dépendent du module maitre hpclr-wrapper. Pour charger ce module, utiliser

la commande :

Il suffit ensuite de choisir le compilateur ou la librairie visée parmi la liste disponible grâce à la

commande :

~$ module load hpclr-wrapper

~$ module avail ------- /opt/cluster/softs/gcc-4.6.x-soft/system/module/3.2.10/Modules/3.2.10/modulefiles --------------- blas-gcc gcc-4.6.4 lapack-3.4.2-gcc otb-4.0-gcc-cgal readline-6.2-gcc boost-1.48.0-gcc gcc-4.8.2 ncurses-5.9-gcc otb-4.0-icc rumd-1.2.2-gcc bzip2-1.0.6-gcc hdf5-1.8.11-intel netcdf-c-4.3-intel python-2.7.5-gcc rumd-2.0.1-gcc bzip2-1.0.6-intel numpy-1.7.0-gcc python-2.7.5-intel ScaLAPACK-2.0.2-gcc cmake-2.8.11.1-gcc hpclr-wrapper openmpi-1.6.5-gcc python-2.7.5-softs-intel use.own cuda-4.2.9-gcc intel-13.0.1 openmpi-1.6.5-intel python-2.7.5-V2-intel zlib-1.2.8-gcc cuda-5.0.35-gcc intel-14.0.2 openmpi-1.8.1-gcc python-3.4.0 zlib-1.2.8-intel fftw3-3.3.3-intel itk-4.5.2 otb-4.0-gcc R-3.0.1-gcc


23

Puis pour charger un module (par exemple le module intel-14.0.2) :

A noter qu'il est possible d'utiliser la complétion automatique (tab) pour gagner du temps. Il est

aussi possible de chainer les modules dans l'ordre de dépendance (module load hpclr-wrapper

intel-14.0.2).

Si le module hpclr-wrapper n'a pas été chargé auparavant, comme le module intel-14.0.2

dépend de ce dernier, le message donné par le système sera le suivant :

Il en sera de même pour toute dépendance non respectée par la suite (par exemple openmpi-

1.6.5-intel vis à vis du compilateur intel, etc).

Il est possible d’observer les ajouts apportés par un module en utilisant la commande :

Pour décharger un module, il est possible d'utiliser la commande :

Pour connaitre la liste des modules déjà chargés :

~$ module list

Exemple d’utilisation, pour compiler le fichier mysource.c avec le compilateur icc d’Intel. Les

lignes commençant par # sont des commentaires.

~$ module load intel-14.0.2

~$ module load intel-14.0.2 intel-14.0.2(18):ERROR:151: Module 'intel-14.0.2' depends on one of the module(s) 'hpclr-wrapper' intel-14.0.2(18):ERROR:102: Tcl command execution failed: prereq hpclr-wrapper

~$ module show intel-14.0.2

~$ module unload intel-14.0.2


24

Dans le cas où la librairie ou le programme désirés ne figureraient pas dans la liste, il est

possible de faire une demande au support HPC@LR. Il est possible aussi de les compiler sois

même, puis d’utiliser les variables d’environnement pour permettre au compilateur d’accéder à

la librairie ou au shell d’exécuter le programme sans avoir à spécifier le chemin complet.

Pour rajouter un programme à la liste des programmes utilisés par le shell :

Pour rajouter une librairie à la liste des librairies disponibles pour le compilateur et les

programmes :

# Modules chargés au début ? ~$ module list Currently Loaded Modulefiles: 1) use.own # Quelle est le gcc utilisé par défaut ? ~$ which gcc /usr/bin/gcc # Chargement du module maitre ~$ module load hpclr-wrapper ~$ which gcc /gpfs2/cluster/softs/wrapper/gcc ~$ gcc 'No gcc modules load, please load a compiler module' # Chargement de gcc-4.8.2 ~$ module load gcc-4.8.2 ~$ gcc gcc: fatal error: no input files compilation terminated. # Présence du compilateur intel ? ~$ icc 'No intel modules load, please load a compiler module' # Chargement du module intel-14.0.2 à la place du module gcc-4.8.2 ~$ module unload gcc-4.8.2 ~$ module load intel-14.0.2 ~$ icc icc: command line error: no files specified; for help type "icc -help" # Compilation du fichier ~$ icc mysource.c -o myprogram.exe

export PATH=/chemin/vers/mon/binaire:$PATH


25

6.2 Compilation avancée : optimisation

Afin de tirer le meilleur parti d’un cluster et d’économiser des heures de calcul tout en favorisant

la performance énergétique, il convient de prendre l’habitude d’optimiser les codes avant de

lancer l’exécution finale du code de calcul.

Les options d’optimisation sont différentes en fonction des compilateurs utilisés. Les flags

recommandés sont regroupés dans le tableau suivant et couvrent les compilateurs gcc, icc,

gfortran, ifort. Note : les options de compilation de code C (gcc/icc) s’appliquent généralement

aux codes C++.

Compilateurs Options de compilation

gcc/gfortran

-march=native -mtune=native -O3

icc/ifort

-xHOST -O3 -ip Possibilité d’utiliser -no-prec-div mais engendrera une légère perte de précision sur les divisions. Possibilité d’utiliser -ipo à la place de -ip si le programme le supporte (compilation longue). Si la compilation ou le programme rencontrent des problèmes, retirer -xHOST et ne laisser que -O3.

Il est TRES fortement recommandé d’utiliser ces options de compilation si le code utilisé le

permet. Il est aussi recommandé d’utiliser les compilateurs Intel au lieu des compilateurs Gnu.

Les correspondances sont les suivantes :

GNU INTEL

gcc

icc

gfortran

ifort

g++

icpc

export LD_LIBRARY_PATH=/chemin/vers/ma/lib:$LD_LIBRARY_PATH


26

6.3 Compilation avec OpenMP

Les versions récentes des compilateurs intègrent désormais la librairie OpenMP nativement. Il

est cependant important de connaitre les options de compilation les activant :


gcc/gfortran

-fopenmp

icc/ifort

-openmp

6.4 Compilation avec MPI

La compilation de code MPI repose sur une librairie externe ainsi qu’un système de wrappers

fourni avec cette même librairie. HPC@LR utilise la suite OpenMPI pour profiter au mieux du

réseau infiniband lors des communications MPI.

Il est important de noter que les dernières versions des suites MPI fournissent toujours un jeu de

wrappers à utiliser pour faciliter le lien avec la librairie et les headers.

Sur HPC@LR, la compilation de code MPI requiert le chargement d’un module de suite MPI. Il

est recommandé d’utiliser OpenMPI. L’exemple suivant montre le chargement du module

openmpi-1.6.5-intel. Ce dernier requiert le module intel-14.0.2 lui-même dépendant du module

hpclr-wrapper.

D’une manière générale, pour compiler un programme MPI, il convient d’utiliser les wrappers

suivants, équivalents à l’appel du compilateur chargé (Intel si le module Intel a été chargé, Gnu

si le module Gcc a été chargé) et la librairie d’OpenMPI :

~$ module list Currently Loaded Modulefiles: 1) use.own ~$ mpicc mpiicc: command not found ~$ module load hpclr-wrapper ~$ mpicc 'No gcc modules load, please load a compiler module' ~$ module load intel-14.0.2 ~$ module load openmpi-1.6.5-intel ~$ mpicc icc: command line error: no files specified; for help type "icc -help" ~$


27

Language Wrapper MPI

C

mpicc

Fortran

mpif90

C++

mpic++

Ces wrappers acceptent les mêmes options d’optimisation que vues précédemment.


28

7 Soumission de job

La dernière phase de cet apprentissage passe par la soumission d'un job au job scheduler.

Les nodes de calcul ne sont pas joignables directement, ce afin de partager les ressources entre

les utilisateurs.

Il est donc nécessaire de préparer un script de soumission (en deux parties si calcul MPI, vu

ci-dessous en 7.2), qui permettra au job scheduler d'exécuter le programme selon les besoins

de l'utilisateur.

Il est important de noter que les librairies et compilateurs utilisés pour compiler le programme

doivent aussi être chargés dans ce script, le programme ayant besoin de certaines parties du

compilateur et des librairies pour s'exécuter.

Une fois le script rédigé, l’utilisateur soumet le script au job scheduler (aussi appelé

soumission de job, par l’intermédiaire de la commande llsubmit). Si le script fourni est

conforme, le job scheduler retourne un numéro de job qui permettra ensuite de suivre

l’évolution du job ou de l’annuler. La soumission de job et la manière de rédiger les scripts

dépendent de l’utilisation visée (MPI, OpenMP, etc), ces aspects sont abordés par la suite.

Quelques commandes utiles une fois le job soumis et le numéro du job obtenu par le job

scheduler :

Fourni la liste des jobs en cours au nom de l’utilisateur

Où jobid est le numéro du job à analyser, fourni l’état du job portant le numéro jobid.

Annule le job portant le numéro jobid.

Ces commandes fournissent les bases de l’interaction avec le job scheduler une fois le job

soumis.

Note : lors de l’exécution par l’intermédiaire du job scheduler, il est possible de voir apparaitre

l’erreur suivante :

~$ llq -u monlogin

~$ llq -s jobid

~$ llcancel jobid


29

Cette erreur est considérée comme normale et n’a aucun impact sur le bon fonctionnement du

système et des calculs. Il est donc recommandé de l’ignorer.

7.1 Organisation d’un script de soumission

Les scripts de soumission sont au format LoadLeveler (nom du job scheduler). Un script

standard de soumission contient en début de fichier les instructions suivantes (à modifier selon

les besoins de l’utilisateur) :

#!/bin/sh # @ job_name = openmptest # @ output = $(job_name).out # @ error = $(job_name).err # @ class = intel # @ account_no = mygroup # @ node_usage = not_shared # @ job_type = mpich # @ node = 1 # @ restart = no # @ total_tasks = 1 # @ environment = COPY_ALL # @ wall_clock_limit = 04:00:10,04:00:00 # @ queue

Avec :

job_name : l’intitulé du job (apparaitra sous ce nom dans la liste d’attente des jobs)

output : le nom du fichier de sortie du job, qui contiendra l’ensemble de ce qui est en

temps normal affiché à l’écran. $(job_name) indique que l’intitulé du job est utilisé

comme base pour le nom du fichier de sortie

error : le nom du fichier de la sortie erreur du job

class : défini le type de node visé :

- intel : node 12 cœurs pour calculs MPI ou multithreads à 12 cœurs

-bash: BASH_FUNC_module(): line 0: syntax error near unexpected token `)' -bash: BASH_FUNC_module(): line 0: `BASH_FUNC_module() () { eval `/opt/cluster/softs/gcc-4.6.x-soft/system/module/3.2.10/Modules/$MODULE_VERSION/bin/modulecmd bash $*`' -bash: error importing function definition for `BASH_FUNC_module' /bin/sh: BASH_FUNC_module(): line 0: syntax error near unexpected token `)' /bin/sh: BASH_FUNC_module(): line 0: `BASH_FUNC_module() () { eval `/opt/cluster/softs/gcc-4.6.x-soft/system/module/3.2.10/Modules/$MODULE_VERSION/bin/modulecmd bash $*`' /bin/sh: error importing function definition for `BASH_FUNC_module'


30

- smp : node 80 cœurs pour calculs multithreads 80 cœurs

- gpu : node contenant 2 accélérateurs NVIDIA

account_no : définit le nom du compte utilisé pour le décompte des heures de calcul

(généralement le nom du groupe d’utilisateurs)

node_usage : indique si le partage de node avec d’autres utilisateurs est autorisé. Il est

recommandé, pour des raisons de performances, de laisser not_shared.

job_type : indique le type de job visé, mais dépend de la class utilisée en réalité :

- mpich : à utiliser pour les jobs de class intel (mpi ou serial)

- parallel : à utiliser uniquement pour les jobs de class smp

node : défini le nombre de nodes désirées :

- si calcul sur class smp : 1

- si calcul sur class gpu : 1 pour 1 ou 2 gpu sans MPI, 2 pour 4 gpu avec MPI, 4

pour 8 gpu avec MPI

- si calcul sur class intel : 1 pour 12 cœurs avec ou sans MPI, 2 pour 24 cœurs

avec MPI, 3 pour 36 cœurs avec MPI, etc

restart : permet de relancer le job en cas d’erreur, laisser no

total_tasks : défini le nombre de processus MPI à exécuter simultanément, lié à la valeur

de node (mais possibilité de ne pas respecter ces valeurs, pour calculs hybrides par

exemple) :

- si calcul sur class smp : 1 (car pas de MPI)

- si calcul sur class gpu : 2 cartes nvidia par node, possibilité de n’en exploiter

qu’une seule

- si calcul sur class intel : 12 cœurs par node, donc 12 processus MPI par node

environment : laisser COPY_ALL

wall_clock_limit : indique la durée maximal du calcul (5 jours maximum, 2 jours garantis).

Il est important de noter que plus la durée indiquée est longue, plus le job mettra de

temps à remonter la file d’attente et à être exécuté. La durée est au

format heures:minutes:secondes. Si le job n’est pas terminé à la fin de cette durée, il

sera automatiquement tué.

Par exemple pour 4 heures de calcul : 04:00:10,04:00:00

La seconde valeur définie la durée exacte voulue, la première est une indication pour le

système et sera fixée à quelques secondes maximum de plus (10s) que la seconde

valeur pour que le système accepte le job

queue : laisser tel quel

Ces valeurs sont essentielles au job scheduler. En cas d’incohérence des valeurs, le job sera

refusé, un message explicit sera fourni à l’utilisateur :

llsubmit: 2512-052 Submit Filter /home/loadl/FILTRE/filtre_prod: rc = 10. llsubmit: 2512-056 Unable to process the job command file "smp.job". llsubmit: 2512-051 This job has not been submitted to LoadLeveler.


31

7.2 Soumission de job pour une exécution sur plusieurs nodes :

MPI

Pour des raisons de stabilité, il est nécessaire de renseigner 2 scripts de soumission pour un

calcul MPI : le UpperSubmit script et le Submit script. Il est aussi nécessaire de faire figurer

dans chaque script la commande module chargeant l’environnement. Le UpperSubmit script est

exécutable et appelle le second, permettant une cohérence d'environnement sur l'ensemble des

nodes de calcul, notamment vis-à-vis de l’environnement module. (En réalité, l’UpperSubmit-

script charge l’environnement sur toutes les nodes escales, et le Submit-script charge

l’environnement sur la node maitre).

Voici un exemple de scripts pour un code "hello world" en MPI indiquant en plus le rang du

processus et le nom de la node utilisée, sur 24 cœurs de calcul (soit 2 nodes distinctes, chaque

node possédant 12 cœurs). Ce code a été compilé avec le compilateur intel-14.0.2 et la librairie

openmpi-1.6.5-intel. Il est important de noter que les modules correspondants sont chargés

dans les deux scripts.

Code MPI utilisé (Fortran 90) :

La compilation du code est faite de la manière suivante :

~$ module load hpclr-wrapper intel-14.0.2 openmpi-1.6.5-intel ~$ mpif90 -O3 -xHost -ip monprograme.f90 -o /scratch/monlogin/monprogram.exe

Une fois compilé, ce programme porte le nom monprogram.exe pour cet exemple.

program hello_world use mpi implicit none integer :: rank, nb_mpi_procs, ierror, hostname_len character (len=MPI_MAX_PROCESSOR_NAME) :: hostname !To enhance code readability, we let MPI call or MPI native variables !in capital letters call MPI_INIT(ierror) call MPI_COMM_SIZE(MPI_COMM_WORLD, nb_mpi_procs, ierror) call MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierror) call MPI_GET_PROCESSOR_NAME(hostname,hostname_len,ierror) print*, 'Hello world ! I am proc',rank,'on',nb_mpi_procs,'procs.I am running on',hostname ! Say hello call MPI_FINALIZE(ierror) end program hello_world


32

Scripts de soumission :

Fichier UpperSubmit-intel.sh :

Fichier Submit-intel (penser à remplacer mygroup par le groupe de soumission de

l’utilisateur) :

Note : mpirun est la commande permettant d’exécuter un programme en parallèle type MPI.

Il reste ensuite à soumettre le “job” au job scheduler. L’exemple suivant est tiré d’un cas

d’utilisation réelle du cluster afin d’être le plus complet possible. Rappel : les lignes commençant

par le symbole # sont des commentaires.

#!/bin/sh module load hpclr-wrapper intel-14.0.2 openmpi-1.6.5-intel llsubmit Submit-intel

#!/bin/sh # @ job_name = mpitest # @ output = $(job_name).out # @ error = $(job_name).err # @ class = intel # @ account_no = mygroup # @ node_usage = not_shared # @ job_type = mpich # @ node = 2 # @ restart = no # @ total_tasks = 24 # @ environment = COPY_ALL # @ wall_clock_limit = 01:00:10,01:00:01 # @ queue module load hpclr-wrapper intel-14.0.2 openmpi-1.6.5-intel cd /scratch/monlogin/mondossierdecalcul mpirun -x LD_LIBRARY_PATH -np $LOADL_TOTAL_TASKS -machinefile $LOADL_HOSTFILE /scratch/monlogin/monprogram.exe


33

Une fois le calcul terminé, tout ce qui a été affiché par le programme dans le terminal du job se

trouve dans les fichiers mpitest.out (sortie normale) et mpitest.err (sortie erreur). Ces fichiers

permettent de s’assurer que le programme s’est bien exécuté.

7.3 Exécution sur une node unique : OpenMP, Pthread

# Rendre l’ UpperSubmit script executable ~$ chmod +x UpperSubmit-intel.sh # L’exécuter, le système retourne un numéro de job ~$ ./UpperSubmit-intel.sh *** Ce travail sera comptabilise sur le projet: 'mygroup' llsubmit: Processed command file through Submit Filter: "/home/loadl/FILTRE/filtre_prod". llsubmit: The job "io01.64157" has been submitted. # L’id du job est donc io01.64157. Cet id permet d’avoir des renseignements sur l’état du job (en file d’attente, en cours de démarrage, en train de tourner, terminé, autre). ~$ llq -s io01.64159 ===== EVALUATIONS FOR JOB STEP io01.64159.0 ===== Step state : Idle Considered for scheduling at : mer. 01 oct. 2014 15:24:42 CEST Top dog estimated start time : dim. 05 oct. 2014 08:04:09 CEST […] Not enough resources to start now. […] Not enough machines to start step io01.64159.0, available = 17, needed = 20 ~$ # Step state =Idle, le job est en attente, le cluster ne dispose pas encore des ressources nécessaires au lancement, d’autres utilisateurs utilisent déjà les nodes de calcul. Patience. #Après 2h d’attentes (prévoir 24h pour les gros jobs) : ~$ llq -s io01.64159 ===== EVALUATIONS FOR JOB STEP io01.64159 ===== Step state : Running Since job step status is not Idle, Not Queued, or Deferred, no attempt has been made to determine why this job step has not been started. ~$ # Step state =Running, le job est en train de tourner sur le cluster. Si la commande avait été passée au moment du démarrage (phase de quelques dizaines de secondes), l’état n’aurait pas été Running mais Starting.


34

Contrairement aux calculs MPI, il n’est pas nécessaire d’utiliser 2 scripts, seul le script au format

job scheduler suffit.

Il existe 2 types de nodes disponibles pour ce type de calcul : les nodes standards dites 12

cœurs (Intel), et les nodes à large mémoire dites 80 cœurs (SMP). Deux exemples sont

disponibles pour ces deux cas de figure.

Voici un exemple de script de soumission pour un code de type "hello world", compilé avec le

compilateur intel-14.0.2 et utilisant la librairie fftw-3.3.3-intel. Le premier exemple soumet le job

sur une node de type 12 cœurs, le second sur une node de type 80 cœurs.

7.3.1 Node Intel :

Fichier script-intel-12c :

Puis pour soumettre ce job, exécuter la commande llsubmit (permet de passer le script au job

scheduler) suivie de la position/nom du script. Le job scheduler retournera alors le numéro (id)

du job. Il sera ensuite possible de suivre l’état du job à l’aide de ce numéro.

#!/bin/sh # @ job_name = openmptest # @ output = $(job_name).out # @ error = $(job_name).err # @ class = intel # @ account_no = mygroup # @ node_usage = not_shared # @ job_type = mpich # @ node = 1 # @ restart = no # @ total_tasks = 1 # @ environment = COPY_ALL # @ wall_clock_limit = 04:00:10,04:00:00 # @ queue module load hpclr-wrapper intel-14.0.2 fftw-3.3.3-intel cd /scratch/monlogin/mondossierdecalcul # Si le code utilise OpenMP, préciser le nombre de threads. Sans cette commande, le système utilisera les 12 cœurs d'office. export OMP_NUM_THREADS=12 /scratch/monlogin/./monprogram.exe


35

L’exemple suivant est tiré d’un cas d’utilisation réelle du cluster afin d’être le plus complet

possible. Rappel : les lignes commençant par le symbole # sont des commentaires.

#soumission du job : ~$ llsubmit script-intel-12c *** Ce travail sera comptabilise sur le projet: 'mygroup' llsubmit: Processed command file through Submit Filter: "/home/loadl/FILTRE/filtre_prod". llsubmit: The job "io01.64160" has been submitted. #Le job a été accepté, vérification de son état : ~$ llq -s io01.64160 ===== EVALUATIONS FOR JOB STEP io01. 64160.0 ===== Step state : Idle Considered for scheduling at : mer. 01 oct. 2014 15:24:42 CEST Top dog estimated start time : dim. 05 oct. 2014 08:04:09 CEST […] Not enough resources to start now. […] Not enough machines to start step io01. 64160.0, available = 0, needed = 1 ~$ # Le job est en attente, le cluster ne dispose pas encore des ressources nécessaires au lancement, d’autres utilisateurs utilisent déjà les nodes de calcul. Patience. #Après 2h d’attentes (prévoir 24h pour les gros jobs) : ~$ llq -s io01.64160 ===== EVALUATIONS FOR JOB STEP io01.64160.0 ===== Step state : Running Since job step status is not Idle, Not Queued, or Deferred, no attempt has been made to determine why this job step has not been started. ~$ # Step state =Running, le job est en train de tourner sur le cluster. Si la commande avait été passée au moment du démarrage (phase de quelques dizaines de secondes), l’état n’aurait pas été Running mais Starting.


trouve dans les fichiers openmptest.out (sortie normale) et openmptest.err (sortie erreur). Ces

fichiers permettent de s’assurer que le programme s’est bien exécuté.

7.3.2 Node SMP :


36

Fichier script-smp-80c :

Puis pour soumettre ce job, exécuter la commande llsubmit (permet de passer le script au job

scheduler) suivie de la position/nom du script. Le job scheduler retournera alors le numéro (id)

du job. Il sera ensuite possible de suivre l’état du job à l’aide de ce numéro.

L’exemple suivant est tiré d’un cas d’utilisation réelle du cluster afin d’être le plus complet

possible. Rappel : les lignes commençant par le symbole # sont des commentaires.

#!/bin/sh # @ job_name = smpopenmptest # @ output = $(job_name).out # @ error = $(job_name).err # @ class = smp # @ account_no = mygroup # @ node_usage = not_shared # @ job_type = parallel # @ node = 1 # @ restart = no # @ total_tasks = 1 # @ environment = COPY_ALL # @ wall_clock_limit = 04:00:10,04:00:00 # @ queue module load hpclr-wrapper intel-14.0.2 fftw-3.3.3-intel cd /scratch/monlogin/mondossierdecalcul # Maximum 80, moins conseillé. Sans cette commande, le système utilisera les 80 coeurs d'office. export OMP_NUM_THREADS=80 /scratch/monlogin/./monprogram.exe


37


trouve dans les fichiers smpopenmptest.out (sortie normale) et smpopenmptest.err (sortie

erreur). Ces fichiers permettent de s’assurer que le programme s’est bien exécuté.

7.4 Exécution sur une ou plusieurs nodes : GPU-CUDA

#soumission du job : ~$ llsubmit script-smp-80c *** Ce travail sera comptabilise sur le projet: 'mygroup' llsubmit: Processed command file through Submit Filter: "/home/loadl/FILTRE/filtre_prod". llsubmit: The job "io01.64184" has been submitted. #Le job a été accepté, vérification de son état : ~$ llq -s io01.64184 ===== EVALUATIONS FOR JOB STEP io01. 64184.0 ===== Step state : Idle Considered for scheduling at : mer. 01 oct. 2014 15:24:42 CEST Top dog estimated start time : dim. 05 oct. 2014 08:04:09 CEST […] Not enough resources to start now. […] Not enough machines to start step io01. 64184.0, available = 0, needed = 1 ~$ # Step state =Idle, le job est en attente, le cluster ne dispose pas encore des ressources nécessaires au lancement, d’autres utilisateurs utilisent déjà les nodes de calcul. Patience. #Après 4h d’attentes (prévoir 48h pour les gros jobs) : ~$ llq -s io01.64184 ===== EVALUATIONS FOR JOB STEP io01.64184.0 ===== Step state : Running Since job step status is not Idle, Not Queued, or Deferred, no attempt has been made to determine why this job step has not been started. ~$ # Step state =Running, le job est en train de tourner sur le cluster. Si la commande avait été passée au moment du démarrage (phase de quelques dizaines de secondes), l’état n’aurait pas été Running mais Starting.


38

Pour l’exécution parallèle avec CUDA, se reporter au paragraphe traitant de la soumission MPI,

et remplacer la class intel par gpu. A noter que les codes CUDA ne sont en principe pas

supportés par le compilateur intel, il faudra donc utiliser le compilateur nvcc d’NVIDIA

conjointement avec le compilateur GCC.

#!/bin/sh # @ job_name = cudatest # @ output = $(job_name).out # @ error = $(job_name).err # @ class = gpu # @ account_no = mygroup # @ node_usage = not_shared # @ job_type = mpich # @ node = 1 # @ restart = no # @ total_tasks = 1 # @ environment = COPY_ALL # @ wall_clock_limit = 01:00:10,01:00:01 # @ queue module load hpclr-wrapper gcc-4.8.2 cuda-4.2.9 cd /scratch/monlogin/mondossierdecalcul /scratch/monlogin/monprogram.exe

A noter que dans le cas de l’utilisation conjointe d’MPI et de CUDA pour l’utilisation multi-

GPU/multi-nodes, il convient d’utiliser les 2 scripts comme vu dans la section soumission MPI.

La class reste gpu.


39

8 Quelques conseils

8.1 Performances :

Conformément au paragraphe traitant de l’optimisation de code, il est fortement

recommandé d’utiliser au maximum le compilateur Intel, combiné aux flags de

compilation et d’optimisation décrits précédemment.

Il est important, avant de lancer un code en production, de vérifier sa scalabilité (cf

annexe), à savoir sa capacité à accroitre sa vitesse de calcul avec l’accroissement du

nombre de processus/threads alloués au calcul. Par exemple, la plupart des codes

tournant sur les nœuds 80 cœurs SMP vont généralement plus vite en n’utilisant que 32

cœurs au lieu de la totalité des 80 disponibles. De même, certains codes MPI vont de

plus en plus vite au fur et à mesure que le nombre total de nodes allouées augmentent,

puis atteignent un palier avant de décroitre en performance, il convient donc de choisir

avec soin le nombre de nodes allouées au calcul pour éviter le gâchis d’heures de calcul.

Pour plus d’informations sur ce point, se reporter à l’annexe ou contacter le support

HPC@LR.

8.2 MPI :

Favorisez la librairie OpenMPI disponible sur le cluster para rapport aux autres librairies

(IntelMPI, etc). Celle-ci utilise la couche PSM très performante sur le réseau infiniband

QLogic d'HPC@LR.

Il peut arriver que le message d’erreur suivant apparaisse à la soumission :

Contacter le support HPC@LR dès que possible et indiquer ce message. Il arrive en

effet qu’une node bloque et nécessite d’être relancée.

Comme indiqué dans la section performances ci-dessus, vérifier la scalabilité du code

MPI (voir annexe pour plus d’informations).

8.3 OpenMP/Pthread :

PSM was unable to open an endpoint. Please make sure that the network link is active on the node and the hardware is functioning. Error: Could not detect network connectivity node001.12601can't open /dev/ipath, network down (err=26)


40

Comme indiqué dans la section performances ci-dessus, vérifier la scalabilité du code

(voir annexe pour plus d’informations).

Si le code ne nécessite que peu de mémoire, préférer les nœuds à 12 cœurs aux nœuds

à 80 cœurs pour les calculs multithreads, leurs processeurs sont plus rapides.

Si le code est fortement dépendant du socket, utiliser la variable KMV_AFINNITY avec le

compilateur Intel pour binder les threads. La commande "numactl" permet de mapper la

node et de mieux répartir les threads. Pour plus d’informations, se reporter à l’annexe du

document.

8.4 Données :

Sauvegarder les données dès que possible sur l'espace de stockage /home ou /work, et

les rapatrier localement dès que possible.

Profiter des performances de l’espace /scratch pour les calculs.


41

9 Annexe

9.1 Génération d’une clé de connexion permanente

(Pour plus d’informations, voir la documentation du cluster).

Afin de se connecter au cluster sans avoir à retaper le mot de passe à chaque connexion, ou

pour permettre l’utilisation d’un script se connectant automatiquement au cluster, il convient

d’utiliser un système de clés ssh.

La procédure est différente sous Windows, l’utilisateur devra faire appel à puttygen et pageant

(http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html).

Cette méthode sous Windows ne rentre pas dans le cadre de ce document.

Point important : lors de la méthode décrite ci-après, le système va protéger les clés avec une

passphrase, équivalent d’un mot de passe, choisit par l’utilisateur.

Ouvrir un terminal et utiliser la commande ssh-keygen pour générer un jeu de clés (une clé

privée et une clé publique). Pour plus d’informations sur les clés de chiffrement asymétriques, la

page Wikipédia traitant du sujet est plus que complète :

http://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique

A ce stade, le jeu de clés a été généré. La clé privée à sécuriser absolument se nomme id_rsa,

la clé publique qui peut être transmise sans danger se nomme id_rsa.pub.

~$ ssh-keygen -t rsa Generating public/private rsa key pair. # Le système demande où placer la clé, laisser par défaut et valider par la touche Enter Enter file in which to save the key (/Users/#yourusername#/.ssh/id_rsa): # Le système demande alors une passphrase, au choix de l’utilisateur d’en renseigner une ou non Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in id_rsa. Your public key has been saved in id_rsa.pub. The key fingerprint is: 3c:fb:bf:4b:71:13:dd:d5:36:0d:94:6a:??:??:??:?? # Les clés sont générés, il est possible de les voir dans le répertoire caché .ssh du home : ~$ cd ; ls .ssh id_rsa id_rsa.pub ~$


42

La dernière étape consiste à rajouter le contenu de la clé publique dans le fichier authorizd_keys

dans le répertoire caché .ssh dans le home de l’utilisateur sur le clusteur HPC@LR. Il est donc

nécessaire de se connecter au cluster, et de copier/coller le contenu de la clé publique dans le

fichier. Le plus simple est d’utiliser les deux commandes suivantes :

La première commande s’assure que le répertoire .ssh est présent sur le cluster et le crée au

besoin, la seconde envoie la clé publique dans le fichier authorized_keys du cluster.

Il reste à se connecter normalement en ssh au cluster, le mot de passe de l’utilisateur ne devrait

plus être demandé à la connexion. Si une passphrase a été mise sur les clés, la passphrase

sera demandée.

En cas de problèmes rencontrés avec cette procédure, contacter le support HPC@LR.

9.2 Debug de base

Il est possible d’utiliser le compilateur Intel (icc/ifort) pour débugger en partie un code. Les

options de compilation suivantes permettent de détecter une bonne partie de ces bugs

(attention, les warnings à la compilation sont également à prendre en compte) :


ifort

-g -traceback -fpe0 -check all -ftrapuv -fp-stack-check -warn all -no-ftz

icc -g -traceback -check=uninit -fp-stack-check -no-ftz ou -g -traceback -check-pointers=rw

A titre d’information, le compilateur gfortran possède lui aussi des options de debug

intéressantes. Les options de compilation suivantes permettent de détecter une bonne partie

des bugs :


gfortran

-Wuninitialized -O -g -fbacktrace -ffpe-trap=zero,underflow,overflow,invalid -fbounds-check -fimplicit-none –ftrapv

~$ ssh [email protected] umask 077; test -d .ssh || mkdir .ssh ~$ cat $HOME/.ssh/id_rsa.pub ssh [email protected] cat >> .ssh/authorized_keys


43

Le compilateur gcc ne possède pas d’options rapides d’accès de debug hormis le -Wall qui

indiquera des warnings à la compilation. Utiliser dans ce cas un débuggeur comme gdb ou

Valgrind.

9.3 Notion de scaling

La notion de scaling est essentielle à la performance dans l’utilisation d’un cluster parallèle.

Cette notion s’applique aux codes MPI ainsi qu’aux codes OpenMP.

Le constat de base est le suivant : tout code, aussi bien programmé soit-il, fini par ne plus

gagner en performance alors même que les ressources de calcul disponibles augmentent. Par

exemple, un code MPI mettra 120 s à s’exécuter sur 2 nodes intel (soit 48 cœurs), 65s sur 4

nodes, 50s sur 8 nodes, et 80s sur 16 nodes. La performance a donc augmentée avec

l’augmentation des ressources de calculs, puis a atteint un palier avant de chuter. Le

phénomène est identique avec l’augmentation des threads OpenMP. Il arrive en effet un point

où les couts des communications entre les nodes (pour MPI) ou les couts de management des

threads (pour OpenMP) grossissent et deviennent dominant en temps par rapport au temps de

calcul. Il convient donc de connaitre la courbe de scaling de son code pour un cas physique

donné afin de tirer le meilleur parti des heures de calculs fournies.

Il existe deux approches, le strong scaling et le weak scaling, à utiliser en fonction de l’objectif

visé.

Note : dans les exemples suivants, le principe de cœur pour les processus MPI est le même que

pour les threads OpenMP, à la différence près qu’un calcul MPI s’exécute sur plusieurs nodes là

où un calcul OpenMP se limite à une seule node. La quantité de cœurs en jeux est donc plus

importante avec MPI qu’avec OpenMP.

9.3.1 Strong scaling

Le strong scaling repose sur une taille du problème physique constant quel que soit le nombre

de cœurs utilisés. Il est généralement utilisé en amont du weak scaling. Le strong scaling

permettra dans certains cas de déterminer l’optimum de taille de domaine par cœur, puis le

weak scaling permettra de connaitre la taille maximale de domaine calculable avec une

performance raisonnable par le code. Cette approche n’est pas optimale (il faudrait itérer) mais

a le mérite de permettre une meilleur efficacité des calculs. Dans le cas d’un domaine physique

de taille déterminée, le strong scaling permet de connaitre l’optimum de cœurs à utiliser pour ce

cas. D’une manière générale, le strong scaling est plus souvent utilisé que le weak scaling.

Soit un domaine physique de taille Tp fixée. Le principe est d’exécuter le calcul sur un faible

nombre de cœurs comme référence, puis d’augmenter ce nombre de cœurs jusqu’à atteindre


44

une faible amélioration du temps de calcul par rapport à l’augmentation du nombre de cœurs. A

noter que si le nombre de cœurs continue d’augmenter, le temps de calcul fini par s’inverser et

augmenter. Le premier test est exécuté avec 12 cœurs, soit une node complète, et donnera le

temps de calcul de référence 𝑇𝑟𝑒𝑓. Les cas suivants se feront avec 24 cœurs (2 nodes), 36

cœurs (3 nodes), etc.

L’accélération est alors donnée par la formule suivante, pour n le nombre de cœurs en jeux :

𝐴𝑐(𝑛) =𝑇𝑟𝑒𝑓

𝑇𝑛

Et l’efficacité est donnée par :

𝐸𝑓(𝑛) = (𝑛

𝑛𝑟𝑒𝑓) ∗ (

𝑇𝑟𝑒𝑓

𝑇𝑛)

Avec 𝑇𝑟𝑒𝑓 le temps de calcul de référence (ici le cas à 12 cœurs), 𝑇𝑛 le temps de calcul du cas à

n cœurs, et 𝑛𝑟𝑒𝑓 le nombre de cœurs en jeux pour le cas de référence.

Exemple (cas MPI, mais identique avec OpenMP) :

Nombre de coeurs Temps de calcul (s)

12 100

24 52

36 36

48 28

60 23

72 21

Il en résulte les courbes d’accélération et d’efficacité suivantes (la courbe rouge représente le

cas parfait) :


45

Le constat est donc le suivant : le code se comporte correctement jusqu’à 60 cœurs (5 nodes).

Les performances se dégradent par la suite. Il convient donc pour ce cas physique fixé de ne

pas dépasser 60 cœurs pour le calcul, sous peine de dégrader l’efficacité du calcul

(performance < 0.8).

9.3.2 Weak scaling

Le weak scaling repose sur une charge de travail constante par cœur de calcul. Par exemple,

une fois la taille de domaine par cœur donnée par le strong scaling, le weak scaling va

permettre de connaitre la taille totale de domaine simulable dans les mêmes conditions.

0

1

2

3

4

5

6

7

0 10 20 30 40 50 60 70 80

Nombre de coeurs

Accélération

0

0.2

0.4

0.6

0.8

1

1.2

0 10 20 30 40 50 60 70 80

Nombre de coeurs

Efficacité


46

Soit un problème physique de taille Tp et un nombre de cœurs utilisés pour le calcul NbC. Dans

le cadre du weak scaling, le choix est fait de définir une taille de domaine physique à simuler fixe

par cœur de calcul, par exemple Tp/64. Chaque cœur va donc calculer une zone de taille Tp/64

durant tous les tests. Le premier test est exécuté avec 12 cœurs (une node Intel), soit une taille

de domaine physique de Tp/64*12 et servira de référence pour le reste des tests. Le second sur

24 cœurs soit une taille de domaine physique de Tp/64*24, puis 36 cœurs pour Tp/64*36, etc.

L’accélération est alors donnée par la formule suivante, pour n le nombre de cœurs en jeux :

𝐴𝑐(𝑛) = (𝑛

𝑛𝑟𝑒𝑓) ∗ (

𝑇𝑟𝑒𝑓

𝑇𝑛)

Et l’efficacité est donnée par :

𝐸𝑓(𝑛) = 𝑇𝑟𝑒𝑓

𝑇𝑛

Avec 𝑇𝑟𝑒𝑓 le temps de calcul de référence (ici le cas à 12 cœurs), 𝑇𝑛 le temps de calcul du cas à

n cœurs, et 𝑛𝑟𝑒𝑓 le nombre de cœurs en jeux pour le cas de référence.

Exemple (cas MPI, mais identique avec OpenMP), le cas présent est indépendant du cas

exposé dans la section précédente strong scaling :

Nombre de coeurs Temps de calcul (s)

12 100

24 102

36 106

48 123

60 150

72 200

Il en résulte les courbes d’accélération et d’efficacité suivantes :


47

Le constat est donc le suivant : le code se comporte correctement jusqu’à 36 cœurs (3 nodes).

Les performances se dégradent par la suite. Il convient donc, pour cette taille de domaine par

cœur fixée, de ne pas utiliser plus de 36 cœurs sous peine de mauvaises performances.

9.4 Optimisation des calculs multithreads

Lors d’une utilisation multithread d’un cluster, le placement des threads peut avoir un impact

colossal sur les performances. De nombreux codes sont plus performants avec 12 cœurs d’une

node Intel plutôt qu’avec les 24.

0

0.5

1

1.5

2

2.5

3

3.5

4

0 10 20 30 40 50 60 70 80

Nombre de coeurs

Accélération

0

0.2

0.4

0.6

0.8

1

1.2

0 10 20 30 40 50 60 70 80

Nombre de coeurs

Efficacité


48

En effet, un nœud Intel d’HPC@LR est composé de 2 processeurs disposants chacun de 12

cœurs. Chaque processeur repose sur un socket. Le socket permet les échanges entre les 12

cœurs du CPU et sa mémoire vive RAM. Les échanges entre les 2 CPU se font par

l’intermédiaire d’un lien QPI, élément lent. Si un thread placé sur un cœur accède à une

mémoire dans son socket, l’accès est proche et rapide. Si ce même thread accède à une

mémoire dans un autre socket, l’accès est beaucoup plus lent et sera d’autant plus lent que le

socket est éloigné. La notion de proximité de la mémoire liée au thread est donc un élément

majeur de performance pour les calculs multithreads.

Cet impact est encore plus fort sur les nœuds SMP (CPUs avec 10 cœurs) possédant 8 sockets

et dont la proximité entre certains couples de socket n’est plus directe mais passe par un

troisième socket (Figure 13).

Figure 13

http://www.qdpma.com/systemarchitecture/systemarchitecture_qpi.html


49

La première étape consiste à analyser la node pour découvrir son organisation et repérer les

positions les plus proches. Pour des raisons de simplicité, la node utilisée ici sera une node Intel

à 2 sockets et composée de processeurs à 8 cœurs (différent d’HPC@LR).

La commande numactl indique ici que la node possède 2 sockets (appelés ici nodes par abus

de langage), et que cette node est composée de 16 cœurs (2 CPUs (‘node’ 0 et ‘node’ 1) avec 8

cœurs chacun) numérotés 0,1,2,3,8,9,10,11 pour le premier socket et 4,5,6,7,12,13,14,15 pour

le second.

Si le code a été compilé à l’aide du compilateur intel (icc,icpc,ifort) seulement, il est possible

d’utiliser la variable KMP_AFFINITY pour indiquer au système de binder (placer) les threads sur

des cœurs bien particuliers ainsi que l’ensemble de leurs données et mémoires locales.

Par défaut, le système place les threads et leur mémoire où bon lui semble, le principe ici est

donc de forcer les positions.

Exemple : le code myprog utilise OpenMP. Le but est donc de savoir quel est la meilleure

utilisation de ce code.

~$ numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 8 9 10 11 node 0 size: 18423 MB node 0 free: 17137 MB node 1 cpus: 4 5 6 7 12 13 14 15 node 1 size: 18432 MB node 1 free: 17479 MB node distances: node 0 1 0: 10 20 1: 20 10


50

Le constat est donc le suivant : l’utilisation de l’ensemble des cœurs de la machine

(OMP_NUM_THRADS=16) est plus performant que l’utilisation de 8 cœurs de la machine en

laissant le système gérer le placement des threads (2 premiers cas). Il y a donc un léger gain à

utiliser plus de ressources de calcul.

L’utilisation de la variable KMP_AFFINITY pour placer les threads en plaçant 4 threads et donc

en utilisant 4 cœurs par socket se comporte comme la configuration par défaut du système (cas

3).

L’utilisation de la variable KMP_AFFINITY pour placer les 8 threads uniquement sur les 8 cœurs

d’un même socket augmente très significativement les performances. Le code utilisé ici est donc

très sensible au placement des threads et à la proximité de la mémoire. La mémoire partagée

(SHARED) est ici accessible localement par l’ensemble des threads, bien plus rapidement que

par un accès via le lien QPI qui relie les sockets. Le prix à payer pour la perte de cette proximité,

même en utilisant plus de ressources de calcul (cas 2), est important. Il vaut ici mieux n’utiliser

que la moitié de la node, ou exécuter deux calculs simultanément sur les deux sockets

indépendamment.

~$ icc -O3 -openmp myprog.c -o myprog.exe # Cas 1 : 8 threads, placement par le système ~$ export OMP_NUM_THREADS=8 ~$ ./myprog.exe Calculation time : 304 s # Cas 2 : 16 threads, placement par le système (le système va utiliser les 16 cœurs) ~$ export OMP_NUM_THREADS=16 ~$ ./myprog.exe Calculation time : 232 s # Cas 3 : 8 threads, placés par groupe de 4 sur chaque socket ~$ export OMP_NUM_THREADS=8 ~$ export KMP_AFFINITY=verbose,granularity=fine,proclist=[0,1,2,3,4,5,6,7],explicit ~$ ./myprog.exe Calculation time : 302 s # Cas 4 : 8 threads, placés tous sur le même socket ~$ export OMP_NUM_THREADS=8 ~$ export KMP_AFFINITY=verbose,granularity=fine,proclist=[0,1,2,3,8,9,10,11],explicit ~$ ./myprog.exe Calculation time : 156 s

Initiation au cluster HPC@LR · inadvertance. Si le mot de passe est toujours refusé après de...

Documents

Transcript of Initiation au cluster HPC@LR · inadvertance. Si le mot de passe est toujours refusé après de...