Version mise à jour le : 1 mars 2012

Les recommandations de l'IDRIS pour le portage de codes depuis Brodie

La machine vectorielle NEC Brodie est arrêtée depuis février 2012 : voici quelques recommandations afin que la migration des codes vers la machine IBM Vargas puisse s'effectuer correctement.

Utilisation de Vargas, les recommandations de l'IDRIS

La structure actuelle de classes de Vargas (en exploitation depuis le 12/01/2009) impose aux utilisateurs d'exprimer dans leurs scripts de soumission LoadLeveler les limites de temps en temps Elapsed (aussi appelé temps de restitution ou temps d'horloge) et non plus en temps CPU. Ce changement a des conséquences importantes sur l'utilisation optimale de la machine Vargas.

Historiquement, on recommandait d'utiliser en début et fin de job les commandes mfget/mfput pour recopier depuis/vers Gaya des fichiers d'entrée ou de résultat. Cette technique est maintenant à proscrire :

les heures comptabilisées pour les travaux parallèles correspondent désormais aux ressources réellement réservées (c-à-d le nombre de cœurs ou cores physiques réservés x le temps Elapsed du travail) et ce, même si ces ressources réservées ne sont pas utilisées. Or, les commandes de transfert mfget/mfput sont séquentielles, un seul cœur est utilisé pendant toute la durée du transfert. Non seulement cela engendre une mauvaise utilisation des ressources, mais surtout l'allocation sera décomptée du même volume d'heures que si tous les cœurs réservés avaient été utilisés (soit un facteur 512 pour 512 cœurs !).
la moindre indisponibilité de la machine fichiers (passage système, panne matérielle) engendre un blocage des travaux sur les commandes mfget/mfput, qui attendent alors que la machine fichiers soit de nouveau opérationnelle pour reprendre les transferts. Le temps Elapsed du travail, lui, continue à s'écouler : le travail peut ainsi éventuellement atteindre la limite de temps Elapsed, alors que son exécution n'est pas terminée. Dans tous les cas, la durée d'attente multipliée par le nombre de cœurs réservés sera facturée.

Une nouvelle gestion du flux des données

Les utilisateurs doivent aujourd'hui privilégier l'utilisation du WORKDIR pour stocker localement leurs fichiers sur la machine de calcul. Comparé à un stockage sur Gaya, les gains en performance (vitesse et en latence d'accès) sont considérables (plusieurs ordres de grandeur) pour des fichiers stockés localement . Attention cependant, l'espace WORKDIR n'est pas sauvegardé, la pérennité des données n'y est donc pas garantie. En cas d'incident grave sur ce système de fichiers, événement que l'on ne peut exclure totalement, certains fichiers pourraient être irrémédiablement perdus. En conséquence, il est à la charge des utilisateurs de recopier régulièrement sur Gaya les fichiers considérés comme importants, parce que sensibles ou encore impossibles à recalculer.

Désynchronisation des parties «calcul» et «transferts de fichiers avec Gaya»

Pour certains utilisateurs qui ont développé des chaînes de traitement complexes mettant en œuvre de nombreux fichiers, il est parfois utile - voire indispensable - de pouvoir chaîner des phases de transfert de fichiers depuis/vers Gaya avec des phases de calcul. Dans ces cas particuliers, il est demandé aux utilisateurs d'isoler et de désynchroniser ces phases de transfert de données utilisant les commandes mfput/mfget, des phases de calcul (séquentiel ou parallèle) . En conséquence, les commandes mfput/mfget ne devraient plus apparaître dans les travaux dits de calcul. Des travaux LoadLeveler multi-étapes comprenant des étapes spécifiques séquentielles seront utilisées pour réaliser ces transferts. À cet effet, une classe dédiée nommée « archive » a été créée. L'aiguillage dans cette classe se fait via l'utilisation du mot clé LoadLeveler « # @ class = archive » dans le script de soumission. Aucune limite de temps n'est à préciser dans cette classe : on hérite par défaut des limites maximum de la classe ( 20 heures en Elapsed) afin de s'affranchir de tout problème ponctuel sur Gaya, via la sécurisation des commandes mfget/mfput. En cas d'incident plus important sur la machine fichiers, cette classe pourra être suspendue en attendant que Gaya soit de nouveau opérationnelle; ainsi aucun transfert ne sera perdu ni aucun travail de calcul affecté par un incident sur Gaya. L'utilisation de cette classe n'est pas facturée; par contre, un suivi est mis en place pour éviter toute dérive de son utilisation.

Choix de l'espace disque à utiliser lors de l'exécution

Lors de l'exécution d'un code, seuls deux types d'espace disque sont accessibles, le WORKDIR et le TMPDIR (il est en effet fortement déconseillé d'utiliser le HOME). L'accès se fait grâce à des variables d'environnement prédéfinies dans le script de soumission du travail (cd $WORKDIR ou cd $TMPDIR). Suivant les caractéristiques du travail, le TMPDIR sera un TMPDIR local (non visible) pour les travaux intra-nœud ou un TMPDIR GPFS partagé (visible) pour les travaux multi-nœuds. Les avantages et les inconvénients liés à l'utilisation de ces différents espaces disque pour l'exécution d'un travail sont résumés dans ces tableaux récapitulatifs. L'IDRIS recommande fortement l'utilisation du TMPDIR, en particulier pour les travaux intensifs en entrées-sorties (I/O) ou pour les travaux qui utilisent fréquemment des fichiers temporaires lors de leur exécution : les performances des I/O y sont bien meilleures et cela se concrétise par une bonne stabilité et des gains significatifs des temps Elapsed des travaux .

Le choix du type d'espace disque optimal à utiliser lors de l'exécution d'un travail est relativement simple : s'il n'est pas indispensable d'avoir la visibilité des fichiers de cet espace disque durant l'exécution (ce qui devrait être le cas genéral), alors il faut utiliser le TMPDIR. Dans les cas exceptionnels ou la visibilité sur les fichiers est indispensable, il faudra utiliser soit le TMPDIR si le travail est parallèle multi-nœuds, soit le WORKDIR dans tous les autres cas. Les travaux multi-étapes sont des cas particuliers pour lesquels on peut toujours utiliser le TMPDIR, espace rémanent d'une étape à l'autre et sur lequel on a la visibilité.

Les différentes étapes d'une exécution type

L'IDRIS recommande de n'avoir recours aux travaux multi-étapes que lorsque cela est vraiment indispensable.
En particulier, si tous les fichiers sont stockés sur le WORKDIR - ce qui est conseillé - il est inutile d'avoir recours à un travail multi-étapes; un travail mono-étape standard est moins lourd à gérer et plus performant (utilisation potentielle du TMPDIR local).

Les travaux multi-étapes ne doivent être utilisés que dans les situations suivantes :

chaînage de travaux ayant des caractéristiques différentes (nombre de cœurs, temps, mémoire), comme par exemple une phase de pré-traitement séquentielle suivie d'une phase de calcul parallèle, suivie d'une phase de post-traitement à nouveau séquentielle (cf. cet exemple),
les fichiers nécessaires à l'exécution du code sont stockés sur Gaya (cf. cet exemple),
on veut sauvegarder des fichiers créés durant l'exécution d'un travail susceptible de tomber en time limit exceeded (cf. cet exemple).

Prototype de travail où les fichiers de l'utilisateur (script de soumission, fichiers d'entrée, exécutable) sont stockés sur le WORKDIR :

se placer dans le TMPDIR,
recopier les fichiers d'entrée et l'exécutable du WORKDIR dans le TMPDIR,
lancer l'exécutable dans le TMPDIR,
recopier les fichiers résultats du TMPDIR dans le WORKDIR.

Voici les exemples de scripts LoadLeveler pour l'exécution d'un code séquentiel, d'un code parallèle OpenMP, d'un code parallèle MPI ou d'un code parallèle hybride MPI+OpenMP.

Une comparaison ligne à ligne d'un job MPI, applicable à tout autre type de travail :

            BRODIE                                                      VARGAS

# ligne obligatoire                                              # ne rien spécifier, shell de connexion pris par défaut
#PBS -S /bin/ksh                                
#PBS -q multi                                                    # @ job_type = parallel

# nom de la requete                                              Nom du travail LoadLeveler
#PBS -N script_sx8                                               # @ job_name = test_MPI

# reservation de 8 processeurs                                   # Nombre de processus demandes
#PBS -l cpunum_job=8                                             # @ total_tasks = 8

# concatene la sortie standard avec l erreur standard            # Fichier de sortie standard, fichier de sortie d'erreur du travail
#PBS -j o                                                        # @ output = $(job_name).$(jobid)    
                                                                 # @ error =  $(job_name).$(jobid)

# temps CPU max par process                                      # n existe pas pour LoadLeveler
#PBS -l cputim_prc=01:00:00
# temps CPU max par job                                          # Temps ELAPSED max. pour l'ensemble du job (1h30mn ici)
#PBS -l cputim_job=04:10:00                                      # @ wall_clock_limit = 1:30:00       
# memoire max par job                                            # Memoire max. demandee par coeur; par defaut stack_limit a 0,5Go
#PBS -l memsz_job=3gb                                            # @ data_limit = 3.1gb  

                                                                 # ligne obligatoire, fin des caracteristiques du travail LoadLeveler.
                                                                 # @ queue

# Echo des commandes passees                                     # Pour avoir l'echo des commandes
set -x                                                           set -x

# On se place dans le repertoire temporaire TMPDIR               # Repertoire temporaire de travail
cd $TMPDIR                                                       cd $TMPDIR
 
# Copie de l'executable depuis le repertoire de soumission       # La variable LOADL_STEP_INITDIR est automatiquement valorisee par 
                                                                 # LoadLeveler avec le repertoire dans lequel on tape la commande llsubmit
cp $PBS_O_WORKDIR/a.out .                                        cp $LOADL_STEP_INITDIR/a.out .
 
# Execution                                                      # Execution
mpirun -np 4 ./a.out                                             ./a.out 

# Sauvegarde des resultats dans le repertoire de soumission      # Sauvegarde des resultats dans le repertoire de soumission
cp solution $PBS_O_WORKDIR/.                                     cp solution $LOADL_STEP_INITDIR

Remarques :

il n'est plus possible de spécifier deux temps distincts, un qui permette d'arrêter le calcul et un autre, plus grand, qui soit la limite du travail. Il n'est possible de sauvegarder ses données en cas de dépassement du temps Elapsed que par l'enchainement d'un step de calcul avec un autre step (cf le multistep),
le fichier de sortie du travail est crée dans le répertoire d'où le travail a été soumis; il est accessible mais il vaut mieux éviter de l'éditer pendant que le travail se déroule,
les commandes de gestion des travaux sont disponibles ici, la structure des classes disponibles est accessible par la commande news class sur Vargas ou dans les pages Web
les limites des classes sur Vargas ont été conçues pour pouvoir accepter tout travail pouvant tourner sur Brodie,

Système de compilation IBM

Vous trouverez dans cette page le moyen d'utiliser le compilateur Fortran xlf sur la machine Vargas; les principales options de ce système de compilation (optimisation, déboggage, endianness) sont décrites ici.

Remarques :

le compilateur Fortran s'adapte automatiquement au suffixe du code source (.f90 = format libre, .f ou .f77 = format fixe); comme sur Brodie il reconnait les .F ou .F90 et passe automatiquement par le préprocesseur cpp. La syntaxe pour passer les options au préprocesseur est la suivante : par exemple
xlf90 -WF,-DVAL_LDA=2401,-DVAL_M=24 -c principal.F90 génèrera un fichier principal.o après avoir préprocessé le fichier spécifié avec les valeurs de VAL_LDA et VAL_M. Plus de précisions dans cette page.
La commande make sur Vargas répond à un standard IBM. Nous vous conseillons plutôt d'utiliser la commande gmake.
Concernant les promotions automatiques des données, l'option -ew employée chez NEC n'a pas d'équivalent strict sur IBM.
Cette option permettait la promotion des entiers ainsi que des réels sur 8 octets, quelle que soit la façon dont ces données étaient déclarées (c-à-d avec ou sans paramètre kind) ; alors que sur IBM :
- la promotion des réels s'effectue grâce à l'option -qautodbl=dbl4;
- seuls les entiers par défaut (c'est-à-dire ceux déclarés sans le paramètre kind) sont promus à l'aide de l'option -qintsize=8.

sur Brodie, la bibliothèque MPI avait la particularité d'être compilée en mode I8R8 (Integer 8 octets, Réels 8 octets) grâce à l'option -ew. Cela permettait de pouvoir promouvoir automatiquement à la fois des variables Fortran et des constantes prédéfinies MPI (comme expliqué au point précédent).
Par exemple, pour le code suivant sur Brodie :

brodie : more bcast.f90
program portage
use MPI
integer           :: code,rang
integer,parameter :: n=2
real,dimension(n) :: a

call MPI_INIT(code)
call MPI_COMM_RANK(MPI_COMM_WORLD,rang,ierr)
a(:)=0.
if (rang == 1) a(:)=2.
call MPI_BCAST(a,n,MPI_REAL,1,MPI_COMM_WORLD,code)
print *,'Mon rang est ', rang,' et mon tableau A vaut ', a
call MPI_FINALIZE(code)

end program portage
brodie : sxmpif90 -ew bcast.f90

brodie01:   mpirun -np 2 a.out
 Mon rang est   0   et mon tableau A vaut   2.000000000000000  2.000000000000000
 Mon rang est   1   et mon tableau A vaut   2.000000000000000  2.000000000000000

Là encore, si on veut utiliser la promotion des variables via une option du compilateur sur Vargas, alors il faut modifier en conséquence les constantes MPI. Dans cet exemple, il est indispensable de changer MPI_REAL en MPI_DOUBLE_PRECISION lors de l'appel à la fonction MPI_BCAST.

vargas : mpxlf90_r -qautobl=dbl4 bcast.f90

vargas:   mpiexec -n 2 a.out
 Mon rang est   0   et mon tableau A vaut   2.000000000000000  2.000000000000000
 Mon rang est   1   et mon tableau A vaut   2.000000000000000  2.000000000000000

Le compilateur NEC acceptait de nombreuses extensions à la norme Fortran, qui ne sont plus prises en compte par le compilateur IBM.
Par exemple au niveau de la syntaxe de l'instruction INCLUDE, il faut encadrer le nom du fichier par des quotes.
```
$ more test_include.f90
program toto

  include mpif.h

end program toto

$ xlf90_r test_include.f90
"test_include.f90", line 3.11: 1515-019 (S) Syntax is incorrect.
** toto   === End of Compilation 1 ===
1501-511  Compilation failed for file test_include.f90.
```
Exécution
- Le type de codage des variables sur Vargas est le même que sur Brodie : Big Endian. Il n'y a donc pas de conversion de vos fichiers existants sur Gaya à prévoir. Cependant, pour les fichiers à accès direct, il est quand même nécessaire de vérifier si on a utilisé ou non les options de promotion des réels sur 8 octets qui existaient sur Brodie, faute de quoi on essaiera d'accéder a des réels sur 4 octets au lieu de 8 (voir le paragraphe precédent).
- Le traitement des fichiers unformatted comportant des enregistrements dont la taille excède 2Gb s'effectue au moyen de la variable d'environnement :
```
export XLFRTEOPTS=uwidth=64 (bash)
setenv XLFRTEOPTS uwidth=64 (csh)
    
```
- Une règle "triviale" qui s'applique à la durée des exécutions : pour un job efficace sur Brodie, à niveau d'optimisation égal (par défaut celui de Vargas est moins agressif que celui qu'avait Brodie), on peut evisager un facteur cinq entre une exécution sur Brodie et la même exécution sur Vargas.
- Il est difficile de savoir quelle mémoire a été consommée par un travail. La façon la plus simple post mortem est de regarder les paramètres mémoire dans la sortie de la commande jar -l : la valeur MAXRSS est sur Vargas l'équivalent du High Memory Watermark sur machine vectorielle. Cette commande permet de plus de monitorer l'efficacité de ses travaux parallèles. Vous pouvez aussi pendant l'exécution utiliser la commande Qstat -r vargas043.numero.0 qui donne le même paramètre en temps réel.
Divers
- Bibliothèques : sur Brodie, on pouvait utiliser la bibliothèque séquentielle de sous-programmes de transformées de Fourier JMFFT, qui émulait la plupart des sous-programmes de transformées de Fourier de l'ancienne bibliothèque CRAY. JMFFT n'est pas installée sur Vargas. Si vous souhaitez l'utiliser, il faudra recompiler les sources sur votre compte. Pour des raisons de performance, nous vous conseillions de migrer à terme vers d'autres types de FFT comme FFTW.
- Déboggage : les aficionados de TotalView retrouveront leur déboggeur favori sur Vargas (voir ici sa mise en œuvre) ; DDT n'est pas disponible.
- Recopie de ses fichiers depuis Brodie sur Vargas:
  1. pour ouvrir un compte dans un projet qui a eu des heures sur Vargas, le chef de projet envoie simplement un FOGEC signé, par fax ou (scanné) par mail.
  2. vous pouvez restaurer vos anciens fichiers de Brodie sur Ulam (ou sur Vargas, le principe comme le logiciel sont identiques), grâce au logiciel Time Navigator.
  3. si vous manquez de place pour cause de quotas disques insuffisants, le chef de projet peut faire une demande d'extension du quota sur le WORKDIR de Vargas (ou d'Ulam) par l'intermédiaire de l'extranet.
© CNRS-IDRIS 2012