CC_Energy (1CPU) |
CC_Opt (1CPU) |
HF_Opt (1CPU) |
B3LYP_Opt (1CPU) |
Gaussian 03 est un logiciel de chimie quantique permettant de réaliser des calculs très variés. Le but de ce document est de présenter les résultats de tests de performances réalisés sur la machine parallèle scalaire de l'IDRIS. Ils ont permis de mettre en évidence l'efficacité de Gaussian utilisé en parallèle et ses limitations dans ce domaine.
Pour tester les performances de Gaussian 03 sur Zahir, un certain nombre de jeux de données ont été utilisé. Ceux-ci ont été repris d'une série de tests réalisée par le NOTUR (le consortium norvégien de calcul hautes performances).
Pour avoir une bonne idée des performances de Gaussian et des différents paramètres qui peuvent les influencer, des tests ont été réalisés en faisant varier un certain nombre d'éléments. La première série de tests a été exécutée en mode séquentiel (un seul processeur), mais en faisant varier la quantité de mémoire réservée. La deuxième a été un test de scalabilité à mémoire par processeur constante. Ensuite, la même série a été effectuée mais cette fois à mémoire totale constante sur un nombre de processeurs variable. Et finalement, l'influence de l'espace disque disponible a été mesurée. Selon les batteries de test, tous les jeux de données ou seulement une partie d'entre-eux ont été sélectionnés.
Pour pouvoir comparer les différents résultats, toutes les exécutions ont été effectuées sur les noeuds p690+ de l'ancienne Zahir. Néanmoins, ils ont été effectué dans des conditions de production et non en mode dédié. Cela a pour avantage de se rapprocher des conditions de travail d'un utilisateur normal, mais cela peut aussi introduire des incertitudes quand aux temps d'exécution car plusieurs travaux peuvent se concurrencer pour accéder, par exemple, aux ressources disques. Les résultats obtenus ici devront donc être considérés avec prudence.
La quantité de mémoire mise à la disposition de Gaussian via la directive %Mem peut avoir une grande influence sur ses performances. Lorsqu'elle calcule les intégrales, l'application les stocke sur disque ou les recalcule selon les options qui lui sont passées ou ses valeurs par défaut. Quand il y a suffisamment de mémoire disponible, les intégrales peuvent également être entièrement stockée en mémoire. Dans ce cas, les performances seront généralement bien meilleures.
Les figures suivantes représente l'évolution des temps CPU et système (en vert) et des temps de restitution (en jaune), ainsi que l'efficacité du job (qui est donnée par (CPU+sys)/elapsed). Ces tests ont été réalisés sur 4 jeux de données différents et uniquement en monotâche. On a fait varier la quantité de mémoire de 500MB à 15GB via la directive %Mem de Gaussian.
| CC_Energy (1CPU) |
CC_Opt (1CPU) |
| HF_Opt (1CPU) |
B3LYP_Opt (1CPU) |
Selon les jeux de données, on constate que la quantité de mémoire allouée peut avoir dans certains cas une influence très positive (CC_Energy et HF_Opt), dans d'autres n'a aucune influence (B3LYP_Opt) et dans d'autres peut avoir un effet négatif particulièrement du côté des temps de restitution (CC_Opt). Il s'agira donc d'estimer correctement ses besoins en mémoire, demander trop n'étant pas toujours le meilleur choix !
Comment estimer ses besoins en mémoire ? Le manuel de Gaussian donne quelques indications à ce propos, mais malheureusement cela ne permet que d'avoir une estimation. La section Estimating Calculation Memory Requirements permet d'évaluer ses besoins minimum qui sont de toute façon très limités par rapport aux ressources de la machine. Par contre, la partie la plus intéressante concerne l'évaluation de la mémoire nécessaire pour stocker en mémoire les intégrales. En effet, si cela est possible (comme pour les tests CC_Energy et HF_Opt), les performances en seront grandement améliorées. Ce stockage est malheureusement très gourmand et est généralement proportionnel à la quatrième puissance du nombre de bases. Pour un calcul du type closed-shell in-core SCF, les besoins sont en N*N*N*N/4. En pratique, on sera donc limité sur les queues jusqu'à 4 processeurs Power4 à des problèmes de maximum environ 350 bases (environ 16GB).
Il faut bien faire attention au fait que ce ne sont que des estimations grossières et qu'il peut y avoir des écarts importants par rapport aux besoins réels de l'application. Il est néanmoins possible de vérifier par après si on a alloué assez de mémoire. Si vous trouvez des lignes commencant par Nreq= dans vos fichiers de sortie, cela signifie que le stockage des intégrales a pu se faire en mémoire. La valeur qui suit vous permet de déterminer la quantité qui a été utilisée. Les unités utilisées sont des mots qui correspondent à 8 octets. Si ces lignes sont absentes, il sera nécessaire de demander (à condition que cela soit possible) plus de ressources mémoire.
Si l'on reprend nos 4 jeux de données, pour CC_Energy et HF_Opt ont alloue suffisamment de mémoire pour le stockage des intégrales au-delà de 8GB. Pour CC_Opt, les besoins étaient très faibles (environ 16MB). Allouer plus n'a donc pas d'effet positif ; la situation étant même dégradée. Tandis que pour B3LYP_Opt, les besoins pour le stockage en mémoire des intégrales n'ont pu être satisfaits (il fallait plus de 21GB).
Une première manière d'optimiser ses jobs Gaussian consiste à estimer correctement ses besoins en mémoire pour stocker les intégrales. Les estimations n'étant que grossières, il est nécessaire de réaliser des essais pour une évaluation plus fine.
La première série de tests d'efficacité parallèle sur Gaussian 03 a été réalisée à mémoire par processeur constante. Cela reflète les besoins minimaux qui croissent avec le nombre de processeurs, mais également la disponibilité croissante de mémoire totale dans les queues parallèles.
Les figures suivantes représente l'évolution des temps CPU et système (en vert) et des temps de restitution (en jaune), ainsi que l'efficacité parallèle du job (qui est donnée par elapsed/(elapsed_1CPU*Ncpu)). Attention : l'efficacité parallèle n'est pas comparable à l'efficacité qui a été utilisée dans le point précédent. L'efficacité parallèle mesure le facteur d'accélération en temps de restitution obtenu par rapport à celui idéal, tandis que l'efficacité mesure le rapport entre le temps passé à calculer et le temps horloge.
HF_Energy (1GB/CPU) |
CBS_Energy (1GB/CPU) |
CC_Energy (2GB/CPU) |
MP2_Opt (1GB/CPU) |
CC_Opt (0.5GB/CPU) |
PCM_Opt (1GB/CPU) |
BLYP_Opt (1GB/CPU) |
HF_Opt (2GB/CPU) |
ONIOM_Opt (1GB/CPU) |
B3LYP_Opt (2GB/CPU) |
Ces résultats montrent que l'efficacité parallèle est généralement acceptable jusqu'à 4 processeurs (sauf pour le test CC_Opt) et dans certains cas jusqu'à 8. Augmenter le nombre de processeurs a pour conséquence (en général) d'augmenter le temps total de calcul et de réduire le temps d'exécution (ou de restitution). Si le nombre de processeurs continue à augmenter, il arrive un moment où les surcoûts de temps de calcul entraînent une augmentation du temps de restitution. Il y a donc une limite à partir de laquelle il n'est plus utile d'augmenter le nombre de processeurs car le coût par processeur devient excessif et l'efficacité parallèle trop faible.
Le cas du test HF_Opt est un peu particulier car on constate une diminution du temps de calcul consommé au-delà de 4 processeurs. Ce phénomène est du à la disponibilité de plus de mémoire (on a travaillé à mémoire par CPU constante) et donc à la possibilité de stocker les dérivées en mémoire. Par contre, le temps de restitution n'a pas été amélioré.
Les résultats étant très différents d'un cas à l'autre, la recherche du meilleur compromis entre temps de restitution et temps de calcul en fonction du nombre de processeurs nécessite d'effectuer des tests pour chaque cas particulier.
La dernière série de tests de scalabilité a été réalisée en conservant la mémoire totale quel que soit le nombre de processeurs.
HF_Energy (1GB) |
CBS_Energy (1GB) |
CC_Energy (2GB) |
MP2_Opt (1GB) |
CC_Opt (0.5GB) |
PCM_Opt (1GB) |
BLYP_Opt (1GB) |
HF_Opt (2GB) |
ONIOM_Opt (1GB) |
B3LYP_Opt (2GB) |
Les constations sont très similaires à celles du point précédent : l'efficacité parallèle est généralement bonne jusqu'à 4 processeurs (à l'exception des tests MP2_Opt et CC_Opt) et parfois jusqu'à 16.
Travailler avec une mémoire totale constante plutôt que qu'une mémoire croissante avec le nombre de processeurs ne donne pas toujours de plus mauvaises performances comme on pourrait s'y attendre.
Encore une fois, des tests doivent être réalisés au cas par cas pour trouver les performances optimales car chaque jeux de données a ses particularités.
Lorsque Gaussian 03 n'a pas assez de mémoire pour stocker les dérivées en mémoire, il peut soit les recalculer, soit les stocker sur disque. Dans ce dernier cas, ses besoins en espace disque peuvent devenir très importants. Par défaut, cet espace est illimité, càd qu'il pourra utiliser tout l'espace disponible sur le système de fichiers ou atteindre la taille maximale de fichier qui peut être créé (environ 64GB sur IBM). Le job plantera alors avec un message d'erreur.
Si l'espace disque disponible spécifié n'est pas suffisant, l'application peut décider de diminuer le nombre de processeurs utilisés. On trouvera dans ce cas dans le fichier de sortie une ou plusieurs lignes similaire à celle-ci : Number of processors reduced to 3 in MP4TCl: NPMax= 16 NPMaxM= 16 NPMaxD= 3. Il faut alors augmenter cet espace disque ou diminuer le nombre de processeurs demandé.
Dans certains cas, diminuer l'espace disque maximum permet d'obtenir de meilleures performances car recalculer certaines valeur peut être moins coûteux que de les relire dans un fichier.
L'espace disque maximum est défini grâce à la directive MaxDisk=xxGB. Si l'on a besoin de plus de 64GB, il est nécessaire de scinder les fichiers temporaires en utilisant la directive %rwf dans le fichier d'entrée. Par exemple, %rwf=test1.rwf,60GB,test2.rwf,60GB,test3.rwf,-1 va permettre à l'application de créer si elle en a besoin trois fichiers, les deux premiers de maximum 60GB et le troisième de taille illimitée.
Les différents tests réalisés ont montré que les performances de Gaussian 03 dépendent de nombreux facteurs et qu'elles peuvent être très différentes d'un jeu de données à l'autre.
Les performances jusqu'à 4 processeurs sont généralement satisfaisantes, mais il est nécessaire de faire des tests au cas par cas pour déterminer les paramètres optimaux.
Dans un premier temps, si vous ne voulez pas tester les différents paramètres, nous conseillons de limiter le nombre de processeurs à 4 et d'essayer de stocker les dérivées en mémoire (possible seulement jusqu'à un peu plus de 300 bases).
Si vous avez de nombreux calculs à effectuer, il est fortement conseillé de réaliser des tests de scalabilité sur des jeux de données caractéristiques afin de trouver les paramètres qui conviennent le mieux à vos jobs. Ce travail de préparation peut potentiellement entraîner des gains de temps de calcul et de restitution importants et donc une meilleure utilisation des ressources qui vous sont allouées.