Ce commit s’inscrit dans la poursuite du travail de parallélisation du code METAFOR et a fortiori dans la chute drastique du temps CPU des simulations de profilage.

Pour rappel, le commit 2089 s’était concentré essentiellement sur les problèmes manifestes de performances de l’assemblage de la matrice de raideur structurale en parallèle, constatés étonnamment suite au commit 2071. Ceux-ci provenaient notamment de la compétition entre les threads OpenMP et tbb.

La figure ci-dessous confirme le retour espéré des performances antérieures au commit 2071, tout du moins pour les simulations lagrangiennes de profilage. Le cas-test est le profilage du channel en formalisme lagrangien. Les courbes en trait plein sont relatives à la révision 2041 de Metafor (tel que présenté à la conférence ICOMP’14 et donc antérieur au commit 2071), les croix à la révision 2089. Le temps de référence du speedup est celui du job à 1 thread de la révision 2041. On peut remarquer des performances plutôt similaires entre les deux révisions de METAFOR, hormis le speedup du buildK en 12 threads désormais encore plus convaincant.

Néanmoins, malgré ce regain de performances, METAFOR accusait une dégradation sévère de ses performances pour les simulations ALE en parallèle de profilage industriel, qui remonte aussi à la révision 2071. Le speedup global était en effet d’environ 0.43 à la révision 2071, relevé à environ 0.5 à la révision 2089. Plus en détails, le speedup du pas eulérien en partie parallélisé au commit 2071 était abaissé à environ 0.32. Le pas eulérien occupait dès lors une part encore plus dominante du temps d’horloge (de l’ordre de 85% avant parallélisation).

Des analyses ont été menées avec l’Amplifier du Parallel Studio. Elles ont pointé des problèmes de performances vers la base de données, largement sollicitée par la convection désormais parallélisée. La synchronisation des threads par le spin mutex défini dans la méthode define() de la base de données était responsable du problème.

Désormais, le vecteur std membre de la classe DBSet est remplacé par un vecteur concurrent pour pouvoir s'affranchir du mutex requis par la méthode define(). Ce choix de vecteur assure, selon la documentation de tbb, que :

• plusieurs threads peuvent agrandir la dimension du conteneur et ajouter de nouveaux éléments de manière concurrente;
• agrandir le conteneur n’invalide pas les itérateurs et indices existants.

Les temps d’accès concurrents dans la base de données ne sont ainsi quasiment plus pénalisés. Toutefois, cela pourrait occasionner une légère dégradation inévitable pour un accès séquentiel par rapport au vecteur std.

A présent, le speedup global de la parallélisation est plus acceptable pour un petit cas-test de profilage en formalisme ALE : environ 4.5 (voir figure ci-dessous). Le speedup de la convection ALE s'élève à environ 7.5.

Une seconde option était le recours à un mutex read-write dans la DB au lieu du spin mutex utilisé auparavant. Les performances étaient cependant plus en retrait que celles de la première option (voir figure ci-dessous).

• Le timer ReZoningStep est ajouté.
• Ajout de la racine du répertoire de travail wDirRoot dans le path et écriture du fichier _init_.py dans wDirRoot. Les fichiers Copra peuvent ainsi être chargés avec l’option de disque local du nœud du cluster permis par launch.py et non plus sur celui du master node.
• Correction d’un problème de visualisation sur les splines.
• Multiples inclusions de tbb dans les cmakeLists.txt pour permettre la compilation sous Visual Studio, suite à l’introduction du vecteur concurrent dans DBSet.h.

— Yanick Crutzen 2014/10/09