Outre les plantages que nous avions rencontrés en rapport avec les accès et agrandissements concurrents de la base de données (cf. mon commit précédent), la mise en place des boucles parallèles dans les opérations de mise à jour du maillage volumes finis (en lieu et place des boucles séries) a entraîné l’apparition d’autres plantages des cas-tests de la batterie. Ces derniers plantages étaient à nouveau peu reproductibles et, à plus forte raison, en configuration de compilation avec débogage. Ils concernaient à nouveau les cas-tests de remaillage (apps.remeshing, apps.remeshing2, apps.welding et apps.welding2). Ils étaient spécifiques au seul compilateur Visual Studio dans son édition 2012. En l’occurrence, ces plantages ne sont pas reproduits avec les compilateurs icc, gcc et clang actuellement installés sur nos stations et ils ne le sont non plus avec le Visual Studio dans son édition 2015.

Pour ces plantages, lorsque je parvenais à les reproduire avec le débogueur du Visual Studio 2012, ce dernier s’arrêtait sur l’initialisation d’un objet statique dans les méthodes getOptimalGpTemplate() du projet mtShapeFunctions ou bien dans les méthodes getStaticShapeFunction() du projet mtGeo. Lorsque ces plantages survenaient, ces méthodes étaient exécutées dans une boucle parallèle qui se trouve dans les opérations de transfert de données. Cette boucle parallèle intervient après les boucles parallèles que j’ai introduites pour la mise à jour du maillage volumes finis. Or, en me renseignant sur les fonctionnalités supportées par Visual Studio, j’ai appris que l’initialisation d’objets statiques de manière concurrente n’est pas supportée par l’édition 2012 mais bien par l’édition 2015. Étonnement, nous n’avons été confrontés, avec l'édition 2012 du Visual Studio, à l’apparition de ces plantages qu’après l’implantation des boucles parallèles de la mise à jour du maillage volumes finis.

Malgré que ces plantages ne soient définitivement plus reproductibles depuis notre migration de Visual Studio 2012 à Visual Studio 2015, nous avons préféré jouer la carte de la sécurité. Nous avons mis en place un patron de conception qui nous assure de ne définitivement plus rencontrer ces plantages dans le cas où nous serions amenés à compiler Metafor avec un compilateur qui ne supporterait pas la fonctionnalité d’initialisation concurrente d’objets statiques. Le patron de conception que nous avons mis en place est décrit ici .

Les objets statiques concernés par ce patron de conception sont très peu sollicités dans le code. Il n’est donc pas opportun de se pencher sur les performances résultantes de cette implémentation.

L’assemblage de la matrice de raideur tangente est réalisé au moyen des méthodes virtual void append(std::vector<int> index, std::vector<double> vals).

On peut remarquer que les deux arguments de ces méthodes sont passés par copie. Dès à présent, ces deux arguments sont passés par référence const.

Conformément à nos attentes, en réalisant un passage de ces deux arguments par référence const en lieu et place d’un passage par copie, nous pouvons observer une très petite amélioration du coût CPU (voir Figure ci-dessous).

Dans les algorithmes de convection du formalisme ALE, nous avons remarqué que les opérations de mises à jour du maillage volumes finis étaient réalisées consécutivement deux fois de suite.

Nous avons modifié le code afin de ne désormais réaliser ces opérations de mises à jour qu’une seule fois et ainsi d’éviter un gaspillage de ressources CPU.

• Ajout d’un timer “ALE_CflMax”.
• Ajout d’un timer “updateBuilders”.
• Le départ du timer “GodunovConvector” est remonté en tout début de la méthode.

A : oo_meta\mtGlobal\Lazy.h

— Yannick Crutzen 2018/01/29